On Thu, 28 Mar 2002, Rogerio Saran wrote:

Thanks a lot for sharing all your research results with us.

> 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.)

The only thing that isn't very nice in this scenario, is that libcurl sends
away the POST data immediately, without waiting for the 100-continue. But
then again, it doesn't set the Expect: header either and thus it is allowed
to perform like this. (It just isn't very wise when POSTing *huge* data that
isn't accepted by the server end.)

> 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:

[snip]

> 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.

"Connection: Keep-Alive" shouldn't mean anything when talking HTTP 1.1.
Connections are always kept alive unless specificly set to "Connection:
close".

> 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.

Ugha.

> 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.

I'd be grateful if you would post a summary of your finding here later, if
you end up with any further insights beyond what you've posted here.

> 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.

First, I'd like to see you report success that this fix actually makes your
application do good. Then, I'd prefer to figure out why this happens. If this
is a IIS flaw, then we might *have to* address this problem in libcurl. Or
even if it is't a flaw, it might be frequent enough to force us to allow this
work-around for libcurl users/developers.

It would also help to hear how the LWP guys have solved this or how come they
don't close the connection even though they get a connection: close?

So, yes, we would be interested in that patch of yours! ;-) Please just post
it here and we can all digest it as we see fit!

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/