W3C home > Mailing lists > Public > public-webapi@w3.org > May 2006

Re: Headers / caches proposal (revised)

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 3 May 2006 17:37:28 -0700
Message-Id: <79735A79-1D97-43E3-984F-564F78D0F303@apple.com>
Cc: Mark Nottingham <mnot@yahoo-inc.com>, "Web APIs WG (public)" <public-webapi@w3.org>
To: Mark Baker <distobj@acm.org>

On May 3, 2006, at 5:19 PM, Mark Baker wrote:

> On 5/2/06, Maciej Stachowiak <mjs@apple.com> wrote:
>> BTW, I don't think "only appended to" solves it, since one of the
>> anticipated problems is that "Close" could be added and may break an
>> existing persistent connection.
> If by "break" you mean "close cleanly", sure.  But there's little harm
> in that in general, since UAs already have to know to start new
> connections if one fails (and another isn't available from the  
> pool). And I would think that being able to close connections could  
> be useful
> in some cases.

I'm not sure network libraries will all react gracefully to a  
"Connection: close" they did not add themselves.

> Alternately, if folks feel strongly about this, we could prevent
> "close" from being added to the Connection header.

That would end up with disallowing "close" and also any header field  
that the XMLHttpRequest client may not set at all, or may only append  
to (since we would not want to allow clients to force the proxy to  
remove the UA-set value). That would be much more complicated than  
the restrictions on any other header field, which are either "you  
can't set it at all" or "you can only add to but not replace the UA  
value". Is being able to set "Connection" a sufficiently compelling  
use case to warrant this additional complexity? Note that we did not  
choose to do this for other headers where some values might be valid  
and interesting but others might be problematic. "Connection" does  
not seem obviously more useful than "Accept-Encoding" for instance.

Received on Thursday, 4 May 2006 00:37:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC