- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 3 May 2006 17:37:28 -0700
- To: Mark Baker <distobj@acm.org>
- Cc: Mark Nottingham <mnot@yahoo-inc.com>, "Web APIs WG (public)" <public-webapi@w3.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. Regards, Maciej
Received on Thursday, 4 May 2006 00:37:48 UTC