- 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