- From: John Panzer <jpanzer@acm.org>
- Date: Mon, 18 Feb 2008 19:15:54 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- CC: mike amundsen <mamund@yahoo.com>, public-appformats@w3.org
Jonas Sicking wrote: > > mike amundsen wrote: >> I've read some threads that lead to me think that the Mozilla plan is >> to block certain HTTP Headers in their implementation of CSR. I can't >> find any details on this and would like some clarification. >> >> What, if any, HTTP Headers are going to be disallowed? Is this for all >> HTTP Methods? > > First off, note that there are no particular headers disallowed when > using the access-control spec in general. I.e. any headers normally > sent with a request will be sent for cross-site requests that use the > access-control spec. > > We do however limit which headers can be set using the > XMLHttpRequest.setRequestHeader method. Looking at the code it > currently only allows "accept" and "accept-language". Not actually > sure what this very short list was based on. I do think we should at > the very least also allow "content-type". If you have any further > suggestions for headers that you think would be safe, do let me know. > > / Jonas > Looking at AtomPub: o Content-Type on POST and PUT is required ("application/atom;type=entry") o If-Match is needed on PUT for optimistic concurrency control o Slug is defined in AtomPub [1] to help suggest URIs Looking elsewhere: o X-Method-Override is used at times to work around intermediaries that can't handle PUT or DELETE. o Cache control headers would be useful to control (specialized scripts may have a better shot at optimizing this than generic browser-only mechanisms). I'd also put in a plea for some type of authorization header. OAuth, AuthSub, and AWS use Authorization: for this purpose, and there's a separate thread on that subject discussing whether that's appropriate. John
Received on Tuesday, 19 February 2008 03:16:10 UTC