Apex Code Development You need to sign in to do that
Don't have an account?
dxjones How can we force HTTP 1.1 (instead of HTTP 1.0, which is the default)
We are coding a web application integrated with Salesforce.com and we have run into several challenges.
The first one is that Salesforce.com replies to HTTP requests with the old-fashioned HTTP 1.0 (instead of the more up-to-date HTTP 1.1)
Is there any way we can *force* an HTTP 1.1 response?
Will HTTP responses be updated to 1.1 with Spring 11?
-- David Jones
replies are normally HTTP/1.1 if the request is
bigmac:code simon$ curl -v https://na1.salesforce.com/services/data/v20.0/recent -H "Authorization:OAuth $SID"
Yes, I understand that is how it is suppose to work.
Except that is not how it works on Salesforce.com.
Here is a specific example you can check yourself.
Using "HTTPFOX" in Firefox, here is the HTTP 1.1 request and the HTTP 1.0 response.
URL =
http://fastcall411.sbox1.cs1.force.com/app/StaticTwiML
HTTP Request =
GET /app/StaticTwiML HTTP/1.1
Host: fastcall411.sbox1.cs1.force.com
User-Agent: Mozilla/5.0 (etc.)
... etc.
HTTP Response =
HTTP/1.0 200 OK
X-Powered-By: Salesforce.com ApexPages
etc.
Will this be fixed in Spring 11?
-- David
So, it appears that the CDN cache that fronts pages in public sites is using http/1.0. I'll see if i can find someone on the sites team to answer your questions (and it using chunked encoding with http 1.0 seems like a bug)
Hi Simon,
Thanks for passing this bug notice along to the "Sites Team". Any word on when they might be able to fix it? This is a problem for us every day. We are waiting for a solution. There must be lots of people getting burned by this error. ... not just responding with HTTP 1.0, but also the chunked encoding, as you observed.
-- David
Hi David,
The use of HTTP/1.0 on Force.com Sites is caused by our reverse proxy caching layer, which uses Squid 2. This version of Squid does not fully support HTTP/1.1, so it advertises HTTP/1.0 instead. It does, however, support chunked encoding and some other HTTP/1.1 features in responses that get sent via Squid, but it cannot handle various HTTP/1.1 features in requests. Additional information about this exists at http://wiki.squid-cache.org/Features/HTTP11 . Squid 3.1 sets the response type to HTTP/1.1 in its responses, though we presently have no roadmap on when this upgrade might happen. As Simon Fell noted, our application server layer uses HTTP/1.1 in its responses, and the use of HTTP/1.0 in responses applies only to Force.com Sites.
You mentioned that this is causing problems, and I'm curious about what problems this is causing. Can you explain them specifically?
Thanks,
Steven Lawrance
I am trying to parse the phrase "This version ... does not fully support HTTP/1.1, so it advertises HTTP/1.0 instead".
Does this mean you kind of mix-and-match some 1.0 and 1.1 features and call it "mostly 1.0" ??
"Transfer-Encoding: chunked" is an HTTP 1.1 feature. It has no place in an HTTP 1.0 response.
Responding to an HTTP 1.1 request, but saying you are speaking HTTP 1.0, but then including (some) 1.1 features looks rather mixed up, doesn't it?
This is like saying you will speak in French tossing in some German words, just for kicks.
How can a company that claims to be at the forefront of cloud computing be so flippant regarding HTTP protocols?
- - - - -
The problem we are encountering is that a "standards compliant" HTTP client is confused by the jumbled up response coming from Salesforce.com. Since HTTP 1.0 does not include any provisions for "Transfer-Encoding: chunked", the (compliant) HTTP client cannot handle an HTTP 1.0 response that comes in several (chunked) pieces.
In practical terms, the response from Salesforce.com gets truncated whenever it exceeds roughly 1000 characters. That is, the HTTP client receives the first chunk (and in HTTP 1.0 there is only every one chunk).
We are prevented from integrating Salesforce.com with another prominent web application, and the source of the problem lies squarely with Salesforce.com
When can we expect this bug to get fixed?
I agree with Simon, "using chunked encoding with http 1.0 seems like a bug".
When can we expect this bug to get fixed?
Hi David,
I'm not disagreeing that it's a bug, and I'm slightly surprised (and slightly not at all surprised) that Internet Explorer doesn't mind it at all. Other web clients are okay with this, though I agree that replying with chunked encoding within HTTP/1.0 isn't great. This is actually the first time that this has been raised as an issue, though that does not diminish the problem.
I cannot make any guarantees around when this might get fixed, but I'll take a closer look at this and will see what can be done within our reverse proxy caching layer. If you have support from Salesforce.com, then feel free to open a customer case for this issue for more one-on-one communication and possible custom workarounds.
Thanks,
Steven Lawrance
I just filed a Support Ticket (aka "Customer Case") regarding this bug.
-- David
As an update on this issue, Force.com Sites now uses HTTP/1.1 in its responses. This means that sandbox uses HTTP/1.1 in its site responses, and *.secure.force.com URLs on production/non-sandbox site responses also use HTTP/1.1.
Production http (non-https) *.force.com and custom web address (www.lincvolt.com, etc) responses continue to be HTTP/1.1, just as they have been all along.