From: Emanuel Norrbin <emanuel.norrbin_at_jitterbit.com>
Date: Mon, 27 Oct 2008 10:17:04 -0700

On Fri, 17 Oct 2008, Emanuel Norrbin wrote:

> HTTP/1.1 100 Continue
> Content-Length: 0
>
> then I send the data and get the following headers back:

I wonder if perhaps the funny Content-Length: after the 100 Continue can cause
some problem.

Did you try sending the POST with Expect: 100 continue disabled?

I have some more info about this. I'm now pretty sure that it is the Expect: 100-continue header that is the problem. So to get around this we introduced an option in the product to turn off this header. It is still not clear if there is a problem with curl or if the server I'm posting is doing something wrong, we have opened a case with them but large companies are not very quick in responding to these kind of things...

I tried to do a 100-Continue post to an Apache server and that works perfectly fine, here is the curl debug output:

CURL DEBUG HEADER_OUT: POST /jitterbit_ws/?id=e802b062-9e21-48a1-ae36-8288669a55f3 HTTP/1.1
Host: localhost:46908
Accept: */*
Content-Type: text/xml; charset="utf-8"
SOAPAction: "Calculate"
Content-Length: 4002
Expect: 100-continue

CURL DEBUG HEADER_IN: HTTP/1.1 100 Continue
CURL DEBUG DATA_OUT: <data out>
CURL DEBUG HEADER_IN: HTTP/1.1 200 OK
CURL DEBUG HEADER_IN: Date: Mon, 27 Oct 2008 16:47:52 GMT
CURL DEBUG HEADER_IN: Server: Apache/2.0.63 (Win32)
CURL DEBUG HEADER_IN: WWW-Authenticate: Basic realm="Restricted Web Service"
CURL DEBUG HEADER_IN: Content-Length: 3596
CURL DEBUG HEADER_IN: Content-Type: text/xml; charset=utf-8
CURL DEBUG HEADER_IN:
CURL DEBUG DATA_IN: <data in>
CURL DEBUG TEXT: Connection #0 to host localhost left intact
CURL DEBUG TEXT: Closing connection #0

In contrast when I post to SalesForce with 100-Continue enabled I get this:

CURL DEBUG HEADER_OUT: POST /services/Soap/c/9.0/4c1600D3000000018EC HTTP/1.1
Host: na2-api.salesforce.com
Accept: */*
Content-Type: text/xml; charset="utf-8"
SOAPAction: ""
Content-Length: 1290
Expect: 100-continue

CURL DEBUG HEADER_IN: HTTP/1.1 100 Continue
CURL DEBUG HEADER_IN: Server:
CURL DEBUG HEADER_IN: Content-Length: 0
CURL DEBUG HEADER_IN: Date: Mon, 27 Oct 2008 17:00:40 GMT

CURL DEBUG DATA_OUT: <data out>
CURL DEBUG HEADER_IN: HTTP/1.1 200 OK
CURL DEBUG HEADER_IN: Server:
CURL DEBUG HEADER_IN: Content-Type: text/xml; charset=utf-8
CURL DEBUG HEADER_IN: Transfer-Encoding: chunked
CURL DEBUG HEADER_IN: Date: Mon, 27 Oct 2008 17:00:41 GMT
CURL DEBUG HEADER_IN:
CURL DEBUG TEXT: transfer closed with outstanding read data remaining
CURL DEBUG TEXT: Closing connection #0
CURL DEBUG TEXT: SSLv3, TLS alert, Client hello (1):
CURL DEBUG UNKNOWN:

So Apache only sends "HTTP/1.1 100 Continue" (which seems to be enough...) but SalesForce sends an empty "Server:" header as well as the "Content-Length: 0" header which seems to be quite unnecessary.... Does the HTTP standard say anything in this regard?

Another thing I noticed is that curl does not send 100-Continue for smaller posts (could it be a 1K limit...). I also tried with an older curl version (7.17.1.0) and that one did not send the 100-Continue header in my test case whereas 7.18.2 does. Has the default POST behavior in curl changed in this respect?

/Cheers
Emanuel

Received on 2008-10-27