Re: [RFC] bandwidth savigns via header eliding

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Mon, 21 Jul 2014 10:52:46 +0200

lör 2014-07-19 klockan 11:35 -0600 skrev Alex Rousskov:

> The above email is talking about a "nnCoection: close" header which
> appears to be a result of a bug in some 15-year old software.
> Identifying that rare header would be overall harmful -- Squid would
> spend more resources on detecting that header presence than it will save
> by removing that header when it is found.

Indeed a valid question.

HTTP divides headers in two groups. end-to-end and hop-by-hop. Assuming
we intend to operate as a semantically transparent HTTP proxy (meaing
one that do not change the meaning of requests/responses) then we MUST
NOT touch end-to-end headers.

The list of hop-by-hop headers is very short. Anything not in that list
is by definition end-to-end unless mentioned in Connetion.

> There are some gray areas like defense against request smuggling, but
> even there extreme care should be taken to avoid harming valid HTTP
> traffic. It is certainly not the area of "delete all bad headers in the
> parser" solutions.

request/response smuggling is different. request/response smuggling uses
incorrectly/ambigiously formatted HTTP to try to make different agents
parse the data stream differently.

As for bandwidth savings then dropping "considered useless" headers will
do very little on bandwidth savings and risk cause a lot of grief.

Much higher bandwidth savings can be acheived by header compression
using a dictionary, but that requires supporting agents on both sides of
the link.

Regards
Henrik
Received on Mon Jul 21 2014 - 08:53:01 MDT

This archive was generated by hypermail 2.2.0 : Mon Jul 21 2014 - 12:00:11 MDT