'Re: HTTPS POST closing connection'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       curl-library
Subject:    Re: HTTPS POST closing connection
From:       Rogerio Saran <rsaran () organox ! com ! br>
Date:       2002-03-28 16:55:48
[Download RAW message or body]

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




[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic