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
