- From: Tyler Close <tyler.close@gmail.com>
- Date: Fri, 8 Jan 2010 15:36:11 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-webapps <public-webapps@w3.org>
On Fri, Jan 8, 2010 at 1:41 PM, Adam Barth <w3c@adambarth.com> wrote: > [[ > In particular, the user agent should not add the HTTP headers: > User-Agent, Accept, Accept-Language, Accept-Encoding, or > Accept-Charset > ]] > > This seems a bit overly constrictive. Maybe we should send "Accept: */*", etc? > > More generally, I suspect the requirements in Section 3.2 violate > various HTTP RFCs. Maybe we should use the term "willful violation" > somewhere? Which RFCs are you referring to? AFAIK, Section 3.2 doesn't violate any MUST requirement in any relevant RFC. There are two uses for this requirement: 1. On browsers that don't yet support any cross-domain API, it would be nice to emulate support by routing the request through the requestor's Origin server. To help ensure the response is the same whether it was sent directly from the user agent or via the Origin server, we omit any information about the sending software. 2. Omitting these headers can significantly reduce message size and so improve performance. > [[ > If the response to a uniform request is an HTTP redirect, it is > handled as specified by [HTTP], whether or not the redirect is itself > a uniform response. If the redirect is not a uniform response, the > user-agent must still prevent the requesting content from accessing > the content of the redirect itself, though a response to a redirected > request might be accessible if it is a uniform response. If the > response to a uniform request is an HTTP redirect, any redirected > request must also be a uniform request. > ]] > > This seems looser than needed. It would be better if the redirect had > to be a uniform response also. There's a note in the spec "The HTML > <form> element can also follow any redirect, without restriction by > the Same Origin Policy", but the <form> element also sends Accept and > User-Agent headers. What's the reason for excluding the headers but > not requiring redirects to be uniform responses? Somewhere in the list archives, I believe there's a message that pointed out a need to remain compatible with existing HTTP redirection software that cannot be (or won't be) updated to include the new header. For example, if the page receives a URL from a URL shortening service, it would be nice to be able to complete the request even if the URL shortening service doesn't return uniform response redirects. The <form> argument makes it clear that following a non-uniform redirect doesn't introduce a security vulnerability. AFAICT, this feature also doesn't lead the resource author into any poor design choices. It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? > What happens with Set-Cookie headers included in uniform responses? > It seems like we ought to ignore them based on the principle that UMP > requests are made from a state store / context that is completely > separate from the user agents normal state store / context. That's a good point. I'll add text to that effect. Thanks, --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Friday, 8 January 2010 23:36:43 UTC