Re: [UMP] Feedback on UMP from a quick read

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