[XMLHttpRequest2] response headers for cross-site requests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[XMLHttpRequest2] response headers for cross-site requests

Anne van Kesteren-2

Currently XMLHttpRequest Level 2 has restrictions on getting response  
headers when doing a cross-site request. I have a feeling these may be an  
artifact of the slightly older model.

getAllResponseHeaders() returns the empty string currently.

getResponseHeader(header) returns null unless header is one of  
Cache-Control, Content-Language, Content-Type, Expires, Last-Modified,  
Pragma.

I think we should be able to change this. (Though we can't expose  
Set-Cookie and Set-Cookie2 obviously.)

Any thoughts?


(I bbc'ed the WAF WG list as there might be some people there interested  
in this. Please reply to the Web API WG list. I'll be happy when this work  
ends up in the same group soonish...)


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest2] response headers for cross-site requests

Jonas Sicking-2

Anne van Kesteren wrote:

>
> Currently XMLHttpRequest Level 2 has restrictions on getting response
> headers when doing a cross-site request. I have a feeling these may be
> an artifact of the slightly older model.
>
> getAllResponseHeaders() returns the empty string currently.
>
> getResponseHeader(header) returns null unless header is one of
> Cache-Control, Content-Language, Content-Type, Expires, Last-Modified,
> Pragma.
>
> I think we should be able to change this. (Though we can't expose
> Set-Cookie and Set-Cookie2 obviously.)
>
> Any thoughts?
>
>
> (I bbc'ed the WAF WG list as there might be some people there interested
> in this. Please reply to the Web API WG list. I'll be happy when this
> work ends up in the same group soonish...)

I'd wonder what the purprose of this is? I.e. what's the usecase?

We don't want to allow access to cookie and authentication headers,
right? Are you sure there are not anything else like it as well that
authors won't unintentionally expose?

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest2] response headers for cross-site requests

Anne van Kesteren-2

On Tue, 08 Apr 2008 19:30:42 +0200, Jonas Sicking <[hidden email]> wrote:
> I'd wonder what the purprose of this is? I.e. what's the usecase?

The main use case for not restricting headers too much is that it gives  
more consistency with same-origin requests. This presumably allows the  
same kind of scenarios that nowadays happen same-origin to be done non  
same-origin.


> We don't want to allow access to cookie and authentication headers,  
> right?

Right.


> Are you sure there are not anything else like it as well that authors  
> won't unintentionally expose?

That's what I'm asking for, I suppose.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest2] response headers for cross-site requests

Jonas Sicking-2

Anne van Kesteren wrote:

> On Tue, 08 Apr 2008 19:30:42 +0200, Jonas Sicking <[hidden email]> wrote:
>> I'd wonder what the purprose of this is? I.e. what's the usecase?
>
> The main use case for not restricting headers too much is that it gives
> more consistency with same-origin requests. This presumably allows the
> same kind of scenarios that nowadays happen same-origin to be done non
> same-origin.
>
>> We don't want to allow access to cookie and authentication headers,
>> right?
>
> Right.
>
>> Are you sure there are not anything else like it as well that authors
>> won't unintentionally expose?
>
> That's what I'm asking for, I suppose.

For what it's worth, I do think that whatever list we come up with
should be part of the access-control spec rather than the XHR2 spec.
This is very much tied in to the security model which is what the
access-control spec describes.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest2] response headers for cross-site requests

Ian Hickson
In reply to this post by Anne van Kesteren-2

On Tue, 8 Apr 2008, Anne van Kesteren wrote:
>
> On Tue, 08 Apr 2008 19:30:42 +0200, Jonas Sicking <[hidden email]> wrote:
> > I'd wonder what the purprose of this is? I.e. what's the usecase?
>
> The main use case for not restricting headers too much is that it gives
> more consistency with same-origin requests.

That's not a use case, it's a language design decision.

I don't think we should change this without a better reason. There's no
reason to believe that some servers don't have information in the headers
that shouldn't be seen by third-parties, and it's the kind of thing that
would be really easy to miss when securing a page for third-party access.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: [XMLHttpRequest2] response headers for cross-site requests

Laurens Holst-2
In reply to this post by Anne van Kesteren-2
Anne van Kesteren schreef:

>
> Currently XMLHttpRequest Level 2 has restrictions on getting response
> headers when doing a cross-site request. I have a feeling these may be
> an artifact of the slightly older model.
>
> getAllResponseHeaders() returns the empty string currently.
>
> getResponseHeader(header) returns null unless header is one of
> Cache-Control, Content-Language, Content-Type, Expires, Last-Modified,
> Pragma.
>
> I think we should be able to change this. (Though we can't expose
> Set-Cookie and Set-Cookie2 obviously.)
I think Location should be included in that whitelist as well. It is not
only used for 3xx redirection headers, but HTTP specifies that it can
also be returned after a 201 Created request, to indicate the URL of the
newly created resource:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2

Similarly, the Content-Location header should also be on the white-list.

Actually, I think all Content-* headers should be on the white-list, so
including Content-MD5, Content-Length, Content-Encoding and Content-Range.

~Grauw

--
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.


lholst.vcf (196 bytes) Download Attachment
smime.p7s (4K) Download Attachment