Re: HTTP client q

[Andrew Moore <Andrew.Moore@xxxxxxxxxxxx>]

My read is

1.0 not valid

1.1 must have for non persistent (aka no Connection: Keep-Alive)

I don't have a mapping of that to "more advanced API" you speak of.

a.

On 14 Nov 2012, at 17:33, Anil Madhavapeddy wrote:

> To the HTTP heads out there, is it ok for a single HTTP request (no 
> pipelining) to always include "Connection: close" in the headers?
> 
> In Cohttp, we currently don't do this, and it appears that every single 
> client has to include the header, or risk the other side not closing the 
> connection cleanly.
> 
> I'm modifying Cohttp to always send the Connection header when a single 
> get/put/post/head request is issued, but *not* when the more advanced 
> pipeline API calls are used.  Does this sound sane?
> 
> -anil


Relevant extract RFC2616 *and there might be something more recent, I can't 
find ight now, it is not clear that the follower RFCs explicitly obsolete this.



HTTP/1.1 defines the "close" connection option for the sender to signal that 
the connection will be closed after completion of the response. For example,

       Connection: close

in either the request or the response header fields indicates that the 
connection SHOULD NOT be considered `persistent' (section 8.1) after the 
current request/response is complete.

HTTP/1.1 applications that do not support persistent connections MUST include 
the "close" connection option in every message.

A system receiving an HTTP/1.0 (or lower-version) message that includes a 
Connection header MUST, for each connection-token in this field, remove and 
ignore any header field(s) from the message with the same name as the 
connection-token. This protects against mistaken forwarding of such header 
fields by pre-HTTP/1.1 proxies. See section 19.6.2.

14.11