Hi there. I did some research on the HTTP specification ( hey what better way to
pass the weekend :) ) and here is what i came up with.

In [rfc7230 section 3][1] it is stated:

> The normal procedure for parsing an HTTP message is to read the
> start-line into a structure, read each header field into a hash table
> by field name until the empty line, and then use the parsed data to
> determine if a message body is expected. If a message body has been
> indicated, then it is read as a stream until an amount of octets
> equal to the message body length is read or the connection is
> closed.

The way to distinguish the length of a message body is stated in
[section 3.3.3][2] where for this particular case, since there is no
Content-Length or Transfer-Encoding header, the end of the body should be
indicated by the server closing the connection.

> Otherwise, this is a response message without a declared message
> body length, so the message body length is determined by the
> number of octets received prior to the server closing the
> connection.

After reading these items I concluded that the client should close the connection
if by parsing the already received header fields it is indicated that a message body is
not expected.

In [rfc7231 section section 6.6][3] it is stated as far as 5xx responses are
concerned:

> The 5xx (Server Error) class of status code indicates that the server
> is aware that it has erred or is incapable of performing the
> requested method. Except when responding to a HEAD request, the
> server SHOULD send a representation containing an explanation of the
> error situation, and whether it is a temporary or permanent

So for the specific 504 response the server should have indicated the end of the
message body by closing the connection.

So you are correct in saying that libcurl cannot distiguish the end of the
response body.

In order for libcurl to work correctly with servers that do not indicate the end
of the message body in any way, an option could be introduced not to wait for a
message body for some specified response codes.

Wget when processing the specific 504 response does close the connection. So an
argument for adding such an option would be since wget does it why not libcurl?

Any chance of that happening?

Anyway this was a fine oportunity to dig into the HTTP 1.1 specification.

Thanks for the prompt response.

[1]: http://tools.ietf.org/html/rfc7230#section-3
[2]: http://tools.ietf.org/html/rfc7230#section-3.3.3
[3]: http://tools.ietf.org/html/rfc7231#section-6.6
[4]: http://tools.ietf.org/html/rfc2119

---
** [bugs:#1387] connection remains open after receiving 504 response**
**Status:** open
**Created:** Fri Jun 27, 2014 09:48 AM UTC by Georgios Nikolopoulos
**Last Updated:** Sat Jun 28, 2014 02:39 AM UTC
**Owner:** Daniel Stenberg
I stumbled upon a peculiar behaviour when testing a transparent web proxy at
work.
In short when the web proxy sends a 504 response as such
HTTP/1.1 504 Gateway Time-out\r\n
Connection: close\r\n
\r\n
without also initiating an active close of the connection then libcurl will wait 
for ever without aknowledging the response until the server terminates.
I managed to reproduce the problem by writing a python script that simulates a
web server always responding with the above 504 response.
when run like this 
    python server.py -s 
which means run the server send the 504 response and initiate an active close then running 
    curl http://127.0.0.1
will terminate with a 504 error response. The server-close.pcap file contains
the packet exchange that takes place in this case.
When run like this
    python server.py
which means that the server will send the 504 response but will not initiate an
active close of the connection libcurl will wait forever. The typical exchange
is shown in server-no-close.pcap.
In this case libcurl achknowledges the tcp segment carrying the 504 response but
will not initiate an active close of the connection. The flow seems to freeze at
this point and no progress will be made unless i intervene with either sending
SIGINT to the curl process or the server.py process.
In contrast the wget utility behaves differently as shown in the
wget-no-close.pcap.
In this case when the 504 tcp segment is aknowledged wget initiates an active
close and the process terminates.
I found in [rfc7230][1] section 6.6 that the client should upon receiving the
response with the Connection:close option initiate a close of the connection. Of
course the same goes for the server but as i understand the server can be less aggresive
in the closing of the connection. Anyway i am not 100% certain what the client
or server expected behaviour should be.
In my case i am using libcurl in some automated tests and the problem is that
serveral clients hang upon receiving such a response. If libcurl showed the same
behaviour as wget then i would be able to perform the tests without problem.
So what do you think? Is this a bug of libcurl or this is the actual behaviour
prescribed by the rfc? Perhaps an option could be introduced that controlled
what should happen in such a case.
[1]: http://tools.ietf.org/html/rfc7230#section-6.6
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.