- **status**: open --> pending-invalid
- **Comment**:

First, I don't think what wget does is a very good indication of what libcurl should do in this case. If wget really closes a connection with the same response, it sounds like they're doing it wrong. I do however guess that the responses differ in some way and thus get the different actions.

In this case, it looks like your server is sending a funny response and that seems where the problem lies and not in the client end. You can actually also work around this problem by making a callback function (like for example the header callback) return error to get the connection failed and disconnected before it would otherwise do it.

---
** [bugs:#1387] connection remains open after receiving 504 response**
**Status:** pending-invalid
**Created:** Fri Jun 27, 2014 09:48 AM UTC by Georgios Nikolopoulos
**Last Updated:** Sun Jun 29, 2014 12:06 PM 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.