Web browsers treat certain request and response headers as forbidden –forbidden request headers are impossible to set in requests, and forbidden response headers are always filtered off of even basic filtered response (i.e. responses for same-origin fetches).
While some of these forbidden request headers make sense generally (for example, Date, Host, Transfer-Encoding), others don't make sense for implementers that don't support CORS or cookies. And the only forbidden response headers (Set-Cookie and Set-Cookie2) only make sense for implementers that support cookies.
To allow different kinds of implementers with different requirements, this change adds a "conformance classes" section defining support for CORS and cookies. It then changes the definitions of forbidden request and response headers to depend on the user agent's conformance classes.
Web browsers treat certain request and response headers as forbidden –forbidden request headers are impossible to set in requests, and forbidden response headers are always filtered off of even basic filtered response (i.e. responses for same-origin fetches).
While some of these forbidden request headers make sense generally (for example,
Date
,Host
,Transfer-Encoding
), others don't make sense for implementers that don't support CORS or cookies. And the only forbidden response headers (Set-Cookie
andSet-Cookie2
) only make sense for implementers that support cookies.To allow different kinds of implementers with different requirements, this change adds a "conformance classes" section defining support for CORS and cookies. It then changes the definitions of forbidden request and response headers to depend on the user agent's conformance classes.