Re: [libmicrohttpd] Connection: close

[Christian Grothoff]

On 12/06/2012 02:51 AM, Eivind Sarto wrote:
> We are using libmicrohttpd (0.9.19) for a http video server.
> One of our customers reported that a video client they were testing failed 
> because the client was setting
> "Connection: close" in the request headers and was expecting a "Connection: 
> close" in the response headers.
> 
> If a client sends a "close" in the request libmicrohttpd does close the 
> connection, but does not add a "close" to the response headers.
> 
> Here is an example showing that the "close" is not added to the response:
> address@hidden ~]$ curl -v -H "Connection: close" 
> http://10.11.1.29/index.html >/dev/null
>> GET /index.html HTTP/1.1
>> User-Agent: curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 
>> NSS/3.13.5.0 zlib/1.2.5 libidn/1.24 libssh2/1.4.1
>> Host: 10.11.1.29
>> Accept: */*
>> Connection: close
>>
> < HTTP/1.1 200 OK
> < Content-Length: 426
> < Cache-Control: max-age=21600
> < Last-Modified: Fri, 16 Nov 2012 02:16:15 GMT
> < ETag: "8221:1353032175:426"
> < Content-Type: text/html
> < Accept-Ranges: bytes
> < Server: MediaBase/8047
> < Date: Thu, 06 Dec 2012 01:22:20 GMT
> < 
> { [data not shown]
> 
> RFC2616 states the following:
> 8.1.2.1 Negotiation
>     An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to maintain 
> a persistent connection unless a Connection header
>     including the connection-token  "close" was sent in the request. If the 
> server chooses to close the connection immediately after
>     sending the response, it SHOULD send a Connection header including the 
> connection-token close. 
> 
> I could easily check for a "close" in the request headers and then add a 
> "close" to the response headers in my server code.
> But, is this something that should be handled by the library itself?
> What do you think?

Eh, tough call --- I'm not sure the 'SHOULD' applies as it is not the
server that *chooses* to close the connection, as the client asked for
it to be closed.  So I'm not sure the RFC clarifies.

Most clients (AFAIK) are fine without the explicit "Connection: close",
so sending it *might* just waste bandwidth.  After all, an HTTP client
that "fails" under the circumstances described above is almost certainly
broken.

OTOH, sending it might also just be polite/helpful (especially for
broken clients, and we generally try to be nice). Right now, as you say,
we leave it to the application, which means that in practice developers
will not think about it, it will work on their systems, and we get no
"Close" header in the situation above.  So then this results in obscure
breakage and manual effort to fix things for the tiny percentage of
cases where it does matter.


My conclusion from this is that we *should* add the close-header (if the
client asked for the closure; if we need it we already do), as it avoids
subtle bugs and the cost (code size, bandwidth) is negligible.

Any opinions to the contrary? Am I missing something?


Happy hacking!

Christian