1

When trying to hit any REST API endpoint in production org with GET request containing parameters in its body, I get 200 as response. However, when doing exactly the same call on a freshly created developer sandbox, I get 411: enter image description here

Any ideas on what might cause this difference in behavior?

1 Answer 1

1

GET requests generally cannot accept a body (nor a Content-Length); this is a restriction of the underlying HTTP protocol, not a Salesforce limitation.

This is called out in RFC 7231, 4.3.1:

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

Also, the Salesforce REST API documentation doesn't even mention that a 411 error code is possible.

Taking a look at the standard HTTP status codes, 411 is described as 411 Length Required. I feel like that might be a bug, as a Content-Length has been provided, but would be unacceptable as a response in this scenario. In theory, the 400 status code should be more appropriate here, as you're violating expectations of the underlying protocol.

Your request should look like:

GET /services/data/v44.0/limits
Authorization: Bearer 00D...
Accept: */*
Host: ...

There should be no Content-Length, and there should be no body. If you intend to send data to the server, you should use PATCH, PUT, or POST. OPTIONS, GET, and DELETE are not specified as accepting a body/payload, and no such body should be supplied.

3
  • Thanks for pointing that out. We are really aiming for consistent behaviour between sandbox and production, and we can't avoid putting data into GET body at this point. Is there any way that we can confirm that this is a bug? It hadn't been happening before couple of months ago.
    – lv1
    Jul 22, 2021 at 10:34
  • 1
    @lv1 Per RFC 7231, 4.3.1: A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. While not specifically disallowed, there is no requirement for a server to accept such a situation. Note that when I said it might be a bug, I meant the 411 is erroneous, but the rejection behavior is acceptable. You should be using a POST to send a payload.
    – sfdcfox
    Jul 22, 2021 at 14:20
  • 1
    @lv1 That is to say, 411 should really only be used when you have a POST/PUT/PATCH with a payload, but no Content-Length is present. A 400 (Bad Request) should be more appropriate in a situation where you provide Content-Length, but it is not allowed. You really can't depend on undefined semantics, as they may stop working or be inconsistent.
    – sfdcfox
    Jul 22, 2021 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.