If I run out of API Requests, is it possible that my queries (in this case, a PATCH to /services/data/v20.0/sobjects/notes) might fail with INSUFFICIENT_ACCESS_OR_READONLY, or would that give a different error message?

The docs simply say:

INSUFFICIENT_ACCESS_OR_READONLY You can't perform the specified action because you do not have sufficient permissions.

Does "sufficient permissions" include API exhaustion, or is it specifically about object permissions?

Going through my logs, I noticed that we hit the API Usage limit same day that we saw a rash of these errors. Are they related, or do I have two problems?

Thanks,

-ck

If I run out of API Requests, is it possible that my queries (in this case, a PATCH to /services/data/v20.0/sobjects/notes) might fail with INSUFFICIENT_ACCESS_OR_READONLY, or would that give a different error message?

The docs simply say:

INSUFFICIENT_ACCESS_OR_READONLY You can't perform the specified action because you do not have sufficient permissions.

Does "sufficient permissions" include API exhaustion, or is it specifically about object permissions?

Going through my logs, I noticed that we hit the API Usage limit same day that we saw a rash of these errors. Are they related, or do I have two problems?

Thanks,

-ck

Hi,

We have just deployed some Https Webservice that are certified with SSL through reverse proxy that supports SNI (http://en.wikipedia.org/wiki/Server_Name_Indication).

With the simple Outbound Message it works fine, but with WebserviceCallout or with HttpRequest we got the following error :

-IO Exception: java.security.cert.CertificateException: No subject alternative DNS name matching "Server Name" found.

Do the both mecanisms (OutboundMessage and HttpRequest) have different libraries underneath ?

Thank you,

Hi,  When we are attempting to get a new access_token using a refresh_token on test.salesforce.com 

https://test.salesforce.com/services/oauth2/token?grant_type=refresh_token&client_id=3....JFK&refresh_token=5....X==

salesforce is returning a return code of 200, but there are 2 Transfer-Encoding Fields with the value of 'chunked' in the response Header

This seems to be out of compliance with http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6

Which states

Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer- coding is used, it MUST be the last transfer-coding applied to the message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message

This behavior is not occuring on our login.salesforce.com instance, and I just noticed that it started happening on Tuesday when my Web client started to reject the double chunked response headers.