W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 2001

Re: Connection: close and 100-continue

From: Roy T. Fielding <fielding@ebuilt.com>
Date: Thu, 8 Nov 2001 16:50:04 -0800
To: Howard Melman <howard@silverstream.com>
Cc: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
Message-ID: <20011108165004.A1887@waka.ebuilt.net>
> I came at it from another spot.  While trying to work around
> an IE bug:
> 
> http://support.microsoft.com/support/kb/articles/Q305/2/17.ASP
> 
> we found our server implementation could do better at
> sending "Connection: close" when it knew it was going to
> close the connection and not just relying on clients to cope
> well with dropped connections.  In trying to get it right, we
> weren't sure if we should send it on 100-continue responses.
> Someone here read:
> 
>    HTTP/1.1 applications that do not support persistent
>    connections MUST include the "close" connection option in
>    every message.
> 
> and thought we needed to send it (a 100-continue response is
> a message so we MUST include it).  It didn't make sense to
> me, thought it could break things, and wanted to check what
> was right.

Oh, I didn't realize you were asking about something that is already
specified incorrectly in the spec.

That is definitely an error in section 14.10 of RFC 2616.  It should say

   An HTTP/1.1 client that does not support persistent connections MUST
   include the "close" connection option in every request message.
   An HTTP/1.1 server that does not support persistent connections MUST
   include the "close" connection option in every response message
   that does not have a 1xx (informational) status code.

since, as you say, it doesn't make any sense to send it on a 1xx message.

....Roy
Received on Friday, 9 November 2001 01:09:58 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:45 EDT