W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Would a header/schema compiler help?

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 3 Aug 2012 10:45:04 -0700
Message-ID: <CAP+FsNcK6E6f2dLT5sLpQ89GAwkZ5x6rvZrDR6wzvuoM9ppfow@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Mike Belshe <mike@belshe.com>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
There is a measured benefit in some situations for header compression. It
does take CPU and memory.
The question isn't if it adds CPU and memory, but rather if the tradeoff is
worthwhile?

This is really something that is best informed by measurements of
transactions in the real world.
Use cases that motivated this design, and thus are potentially interesting:
  mobile devices
  satellite links
  high-loss links (e.g. many links from Africa, where cwnd is usually
ending around 3 packets worth...)
-=R

On Thu, Aug 2, 2012 at 10:30 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> In message <
> CABaLYCtNzTZjUPgknfNtjwhkUopf3gaHQ6SmBGLAywu07WAB1g@mail.gmail.com>
> , Mike Belshe writes:
> >--f46d0407178542016504c64fa910
>
> >> I also have trouble with the use of compression over the headers for two
> >> reasons:
> >>
> >> 1) While we know that compression can work wonders on entity bodies, it
> >> obscures the headers which are critical for inspection and manipulation
> by
> >> everybody down the message path.
> >>
> >
> >So far, this has not been a problem.
>
> ... becuase sites which needed such inspection and manipulation
> deliberately
> stayed away from SPDY because of the TLS+Compression requirement.
>
> Absense of evidence is not evidence of absense.
>
> --
> 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 Friday, 3 August 2012 17:45:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 3 August 2012 17:45:38 GMT