Re: [RFC] bandwidth savigns via header eliding

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
>
Received on Sat Jul 19 2014 - 05:34:32 MDT