* Anne van Kesteren wrote: >> "For security reasons, these steps should be terminated if the header >> argument case-insensitively matches one of the following headers: >> >> * Accept-Charset >> * Accept-Encoding >> * Connection >> * Content-Length >> * Content-Transfer-Encoding >> * Date >> * Expect >> * Host >> * Keep-Alive >> * Referer >> * TE >> * Trailer >> * Transfer-Encoding >> * Upgrade >> * Via " >> >> It's unclear why there's a security reason not to allow things like >> "Accept-Charset" or "Accept-Encoding". Please explain. > >This was done based on implementation feedback. I haven't investigated >what the reasons were for the various headers. If implementors read this >maybe they could chime in and point it out.
Note that there are more headers on the list than the ones listed above, specifically Proxy-*, Sec-*, and it is unclear how to handle, say, the Cookie and Authorization header. The correct value, if any, of the Connection, Content-Length, Expect, Keep-Alive, Trailer, Transfer-Encoding, and Upgrade depends on decisions about how to transfer the message and how to maintain the connection that the implementation alone can make, therefore the implementation rather than the script controls these headers. The Host header is on the list to ensure scripts cannot bypass same origin restrictions. Date, Referer, and Via inform about the origin of the request, they are controlled by the implementation to prevent origin spoofing. The case for these is much less clear, considering that other headers like User- Agent are not on the list, and that cross-site requests are not allowed. Accept-Charset, Accept-Encoding, and TE inform about client capabilities and it seems the worst that could happen for them is that the server offers a response the implementation cannot handle, which the server may do anyway. I don't think their presence is particularily justified. This is also because some environments treat "X-Y" named headers as if they were "X_Y" headers and vice versa, if, say, Accept-Encoding is a problem so would be Accept_Encoding. Why Content-Transfer-Encoding is on the list I have no idea, HTTP does not use this header at all, and when I researched this some months ago, I could not find any particular security problems associated to it, as far as I remember. I very much agree the rationale for each header needs to be in the spec, in a manner that also allows telling why other headers are not. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
