On Wed, Jan 30, 2013 at 2:55 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:
> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <
> CAP+FsNfGocr9S992SQNWfW+K9Rz5f1XZcVkC7AoV5WXmxF+Pcw@mail.gmail.com>,
> Roberto Peon writes:
>
> >Dropping the host header will inflate the size of bytes on the wire, to
> the
> >detriment of latency.
>
> Really ?
>
> I thought we hadn't decided how things would be encoded yet, so how can
> you tell ?
>
>
As far as Delta encoding is concerned, yes, because it means the host would
have to be specified in every request rather than be stored in the context.
Yes, we have not yet decided on the specific encoding yet so you're both
correct.
> As far as I can see, if we did this to HTTP/1 with no other changes we
> would;
>
> Add "http://" ${fqdn}
>
> Remove "Host: " ${fqdn} CR NL
>
> Which looks like a one byte saving to me ?
>
>
I think we can all agree that the host information needs to be there
somewhere. It's just a matter of deciding exactly where it is the most
beneficial. Host is just one of the headers that middle boxes can use to
direct requests, and while it may be perfectly fine to remove the host
header, removing it from the header block does not guarantee that
additional text-processing won't be necessary. (Note, for instance, that if
we just rely on host in the request URI, a particular middle box that
routes just off the host name and not the url will still need to do text
processing).
I'm personally no where near convinced that there's a need to remove Host.
I see it as being quite useful in many scenarios and we have to keep it
around for backwards compatibility with 1.1 impls anyway.
- James
> >I haven't yet heard of a real performance advantage for dropping it. Is
> >there one?
>
> High-performance implementations would not have to text-process the entire
> header to find the fqdn they use for routing decisions.
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>
Received on Wednesday, 30 January 2013 23:13:13 UTC