On 19.04.2010 19:06, Tyler Close wrote:
... 4.2 Response Header FilteringSome 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)?
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?
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?
...
Best regards, Julian
