- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 19 Apr 2010 19:55:02 +0200
- To: Tyler Close <tyler.close@gmail.com>
- 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 19.04.2010 19:37, Tyler Close wrote: >>> 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. Again: did you check all the headers in the permanent registry? If you did, why are the ones (which are just examples) missing? And what's the reason to default to strip general headers and response headers? >>> 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? I'm concerned that by simply dropping the header, you profile too much. >>> 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. That appears to be an issue completely independently of CORS/UMP. If that's the case, it should be mentioned in the HTTPbis security considerations, but doesn't necessarily require blocking. Best regards, Julian
Received on Monday, 19 April 2010 17:55:50 UTC