- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 20 Feb 2008 13:46:51 -0800
- To: mike amundsen <mamund@yahoo.com>
- CC: public-appformats@w3.org
If we can come up with an allowed header list I would be all for that. There is already such a list but it only contains "accept" and "accept-language". Please feel free to suggest additional headers. Preferably as a separate thread as this one is quite ranty, long and covers a range of topics already. / Jonas mike amundsen wrote: > The inability to use standard HTTP Headers like content-type, etag, > if-match, etc. seems unnecessarily restrictive. > > I suggest we establish a list of "disallowed" headers and bake that > into the XmlHttpRequest implementation. We could use an "allowed" > headers list, but that would be going against the spirit of RFC2616. > > Mike Amundsen > > > > On Thu, Feb 14, 2008 at 5:58 AM, Anne van Kesteren <annevk@opera.com> wrote: > > > > On Thu, 14 Feb 2008 06:59:29 +0100, John Panzer <jpanzer@acm.org> wrote: > > > Anne van Kesteren wrote: > > > > >> This is currently not the case for XMLHttpRequest level 2. Based on > > >> feedback from Mozilla only Accept and Accept-Language can be set for > > >> cross-site requests. > > > > > > (Aside: Surely Content-Type is allowed as well?) > > > > Currently, no. > > > > > > > > > This rules out the use of AtomPub's (RFC5023) If-Match: header on PUT > > > for optimistic concurrency control, and the Slug: header[1] on POSTs for > > > suggesting the URI to mint. The first is especially troublesome. > > > > > > It also eliminates the ability to do cache control (except crudely by > > > salting the URL, which of course fills up caches with dead data). It > > > makes it impossible to use the common X-Method-Override work-around for > > > intermediaries which don't support things other than GET and POST. It > > > prevents the use of the Range: header to get a subset of a resource. > > > And of course it prevents the use of any custom X- header for any > > > purpose. > > > > I agree that it provides a lot of limitations. I believe the primary > > concern is not provide new attack vectors. GET requests you can currently > > issue don't allow setting of custom headers, for instance. However, this > > concern does not apply to POST/PUT, etc. as there you make an initial > > request to see if the server is ok with it. > > > > Jonas? > > > > > > > > > > -- > > Anne van Kesteren > > <http://annevankesteren.nl/> > > <http://www.opera.com/> > > > > > > > > > > -- > mca > http://amundsen.com/blog/ > > >
Received on Wednesday, 20 February 2008 21:46:35 UTC