Re: CSR and Mozilla - Clarifying HTTP Header Filtering

John makes a good point.

There are a number of 'non-spec' HTTP Headers in use that should not
be pre-empted. Some Atom servers support the X-WSSE header[1] is
another one. Trying to come up with a list of allowed headers is
really the wrong way to go.

I suggest someone try to make the opposite case - a header that should
not be allowed.

MikeA

[1] Atom Authentication - http://www.xml.com/pub/a/2003/12/17/dive.html

On Feb 18, 2008 10:15 PM, John Panzer <jpanzer@acm.org> wrote:
>
> 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
>
>
>



-- 
mca
http://amundsen.com/blog/

Received on Tuesday, 19 February 2008 03:24:13 UTC