curl-library
Re: HTTPS POST closing connection
Date: Thu, 28 Mar 2002 13:55:48 -0300
Samuel, thank you for the hints on IIS 4 behavior. I checked the whole
connection process with an ssl traffic sniffer and found some
interesting results.
>>> session log fragment
webmitm: 420 bytes from 200.184.134.107
POST /GRIPNET/gracgi.exe HTTP/1.1
Host: bankline.itau.com.br
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
Content-Length: 116
Content-Type: application/x-www-form-urlencoded
...post data...
webmitm: 89 bytes from 200.246.143.202
HTTP/1.1 100 Continue
Server: Microsoft-IIS/4.0
Date: Thu, 28 Mar 2002 11:50:26 GMT
webmitm: 127 bytes from 200.246.143.202
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Thu, 28 Mar 2002 11:50:29 GMT
Connection: close
Content-type: text/html
webmitm: 997 bytes from 200.246.143.202
<html>
<head>
<title>Bankline</title>
>>> end session log fragment
The client application with libcurl is running on the host
200.184.134.107. The target server for the requests is 200.246.143.202.
There is no proxy between the computers.
There is one complete POST request, with its corresponding post data.
Then the server returned two responses... one '100-continue' as it would
be expecting post data (already sent) and then a '200-ok' with a
'Connection: close' header.
It seems an odd behavior from this server (and correct behavior for
libcurl.) I checked the handshake with the same robot running the LWP
native https client, and the connections are kept. There is some
difference on the request headers as follows:
webmitm: 191 bytes from 200.184.134.107
GET /homebanking.htm HTTP/1.1
TE: deflate,gzip;q=0.3
Keep-Alive: 300
Connection: Keep-Alive, TE
Host: bankline.itau.com.br
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
webmitm: 227 bytes from 200.246.143.202
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Thu, 28 Mar 2002 13:00:49 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Thu, 01 Mar 2001 20:30:12 GMT
ETag: "0625e6a8ea2c01:4972"
Content-Length: 4844
webmitm: 4844 bytes from 200.246.143.202
<html>
... document body...
... next request ...
POST /GRIPNET/gracgi.EXE HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE
Host: bankline.itau.com.br
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
Content-Length: 91
Content-Type: application/x-www-form-urlencoded
In the first GET request LWP adds a "Connection: Keep-Alive" header. In
the following POST LWP did not added this, and the response comes with
the same Connection: close header as verified with libcurl.
It seems the native LWP http client ignores the "Connection: close"
header, and keep using the connection while it is open. The IIS server
does not care about its own response and keep the connection open.
This looks like "broken" LWP behavior, according to RFC2616.
"8.1.2.1 Negotiation
... If either the client or the server sends the close token in the
Connection header, that request becomes the last one for the connection..."
This is becomimg OT, from now on I will switch this thread to the LWP
mail group.
For libcurl users: I am considering to patch the library for my own use,
making possible to adjust how it handles "Connection: close" response
headers at user discretion.
If anybody find this feature useful please contact me to get the patch.
Would the library mantainers will accept this as a new standard feature?
I don't think so, but asking can't hurt.
*Saran
Samuel Listopad wrote:
>>>Anybody wonder why libcurl is closing the connection even after
>>>receiving a "continue" response code?
>>>
>>Yes, I wonder why.
>>
>>AFAICR, the 100-response code just eats that and then awaits
>>the next "real" header so it should close the connection
>>because of this.
>>
>
> Don't know if this is helpful at all, but I was playing with some java
> libraries
> Of my own maing the other day and had a similar problem. What happened
> Was hat the IIS page was failing, and Microsoft in its infinite wisdom
> Decided not to return a header with the error message.
>
> So the chain of events was:
> 100 - response
>
> text-only packet
>
> close socket.
>
> And since he java was looking for another header it just failed to
> console.
>
> Don't know if this helps, but thought I would throw it out there.
>
> Sam
Received on 2002-03-28