On 19/07/2014 2:07 a.m., Eliezer Croitoru wrote: > This got my eyes but I am not reading all ietf httpbits mails and I > would like to get a reference for this thread please? >
There are two type of removable headers: a) headers which exist purely to bypass security b) headers which exist due to intermediaries breaking them The post describing why the (b) group occur is here: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0132.html One of the posts which is making me think we could benefit from doing something is: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1220.html This lists the existing headers found in the data sets being analysed by IETF as representative of HTTP web traffic. ie HTTP/2 compression an dimprovements measured What I can see in that listing is the following headers (by type above). (A) group: x-powered-by / x-aspnet-version / x-aspnetmvc-version / x-pb-mii - exists to bypass server security measures applied on Server: header. x-served-by - same as X-powered-by but also crossing over to contain X-forwarded-for: and Forwarded: header contents (but without the security protections applied for them). x-host / x-forwarded-host - exist to bypass Browser same-origin security measures. x-li-uuid - tracking cookie created to bypass Cookie header security and legislative restrictions. x-fs-uuid - header for distributing the UUID of the server hard drive out to the public network (seriously, what could go wrong with that huh?) x-radid - seems to be another disk drive tracking ID method. (b) group worry me for the reasons given below: nncoection / cneonction / x-cnection - reason described in the above email. I am a little bit worried that in HTTP/1.1 these may have actually contained lists of headers which were to be dropped by the earlier intermediary. But obscuring the "Connection:" name we are potentially transmitting headers like Upgrade: or with private details that should be elided. ntcoent-length / cteonnt-length - Given the reason behind 16-bit rotate on header name any of the mandatory HTTP/1.1->1.0 and connection:close addition required to make this safe will alter the checksum. So will content adaptation if that was the point. I am left with assuming that this is done to smuggle messages in a pipeline through the receiving server as a single request/reply. There are also a bunch of other headers which can best be called "garbage". Relatively harmless though. Old HTTP features and mechanisms which are now not supposed to be sent: pragma:close - dead HTTP/1.0 feature. Not to be emitted by HTTP/1.1 software. p3p - dead standard, removed from service due to privacy violations. x-pad - supposedly an HTTPS-only feature for "fixing" proxy-connection - dead non-standard. we already drop this one debug headers that are mostly useless (we could help clean this up by only enabling our x-cache headers based on a debug config option) x-cache / x-cache-lookup / x-cache-action / x-cache-hits / x-cache-age / x-fb-debug / x-mii-cache-hit / bk-server Amos > Thanks, > Eliezer > > On 07/18/2014 10:32 AM, Amos Jeffries wrote: >> Some of the statisticas being brought up in the IETF HTTP/2 discussions >> is highlighting certain garbage headers which are unfortunately quite >> common. >> >> I have wondered about creating a registry of known garbage and simply >> dropping those headers on arrival in the parser. This would be in >> addition to the header registry lookup and masking process we have for >> hop-by-hop headers. >> >> Any other thoughts on this? >> >> Amos >
