- From: Tyler Close <tyler.close@gmail.com>
- Date: Mon, 19 Apr 2010 10:37:07 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Ben Laurie <benl@google.com>, Arthur Barstow <Art.Barstow@nokia.com>, ext Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On Mon, Apr 19, 2010 at 10:20 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 19.04.2010 19:06, Tyler Close wrote: >> >> ... >> 4.2 Response Header Filtering >> >> Some HTTP servers construct an HTTP response in multiple stages. In >> such a deployment, an earlier stage might produce a uniform response >> which is augmented with additional response headers by a later stage >> that does not understand a uniform response header. This later stage >> might add response headers with the expectation they will be protected >> by the Same Origin Policy. The developer of the earlier stage might be >> unable to update the program logic of the later stage. To accommodate >> this deployment scenario, user-agents can filter out response headers >> on behalf of the server before exposing a uniform response to the >> requesting content. If the response includes a Uniform-Headers header >> with a value "*", no response header filtering is required; otherwise, >> the user-agent MUST filter out all response headers other than the >> following: >> >> * Content-Encoding >> * Content-Language >> * Content-Length >> * Content-Location >> * Content-MD5 >> * Content-Range >> * Content-Type >> * Expires >> * Last-Modified >> * Location >> * Warning >> * any header whose name is the value of a Uniform-Headers header >> on the response >> >> Uniform-Headers = "Uniform-Headers" ":" ( "*" | #field-name ) >> >> The default members of the above whitelist include response entity >> headers defined by [HTTP], plus the Location and Warning headers. The > > Why are you ignoring other headers in the permanent registry? Why only allow > entity headers? What the problem, for instance, with "Allow" (RFC 2616), > "Allow-Patch" (RFC 5749) or "Dav" (RFC 4918)? The default members of the whitelist define the minimum set of headers to allow. If the response entity is delivered, then at a minimum, the response entity headers should accompany it, assuming it is safe to do so. I manually vetted those headers. To support redirection, we need Location. Warning is needed in case the requesting content wants to reject stale responses. The server must then explicitly opt into anything beyond the minimum header set. >> default part of the whitelist does not include: headers used for >> credential authentication, such as WWW-Authenticate; nor headers that >> might reveal private network configuration information, such as Via; > > What's the rational for stripping all of the information in Via? Are you suggesting UMP specify an algorithm for filtering out only some Via header values? >> nor caching headers, such as Age, which provide explicit information >> about requests made on behalf of other requesting content. >> """ > > What's the problem with Age, please clarify? Content from one origin can tell exactly how long ago content from another origin requested the cached content. That's at least a privacy issue, and possibly a confidentiality issue. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Monday, 19 April 2010 17:37:40 UTC