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

Re: Performance implications of Bundling and Minification on HTTP/1.1

From: Martin Nilsson <nilsson@opera.com>
Date: Sun, 24 Jun 2012 00:27:47 +0200
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Message-ID: <op.wgdnclbjiw9drz@manganese.bredbandsbolaget.se>
On Sat, 23 Jun 2012 10:29:47 +0200, Poul-Henning Kamp <phk@phk.freebsd.dk>  

> There are two subcases, and they are quite different:
> "Incoming"
> ----------
> Typically a load-balancer which needs only to inspect the "Host:"
> header and/or the URI in the request and the status code of the
> reponse.
> These are the devices I call "HTTP routers", and they are where
> all the traffic bottlenecks when the entire world tries to find
> out what happened in Dallas.
> HTTP/2.0 should serialize (at least) these crucial fields without
> gzip and preferably in a way that makes it very easy and cheap to
> find them.
> "Outgoing"
> ----------
> Almost always content-scanning, and since there are legitimate
> use cases (Prison inmates for instance) we have to accept this
> role as legitimate[1].
> A legitimate argument exists, that censors should pay the cost
> of censorship.  If we accept that, these boxes should not be
> able to force clients/servers to forego compression.

This very quickly moves into the area of policy and not technology, but  
those decisions must be made as well. These are the real world cases I can  
think of right now

- Reading request headers (loadbalancers, logging, url filtering)
- Reading the request payload (legal intercept)
- Modifying request headers (header enrichment)
- Replacing the request (access point sign up, interstitial)
- Reading the response (content based filtering, legal intercept)
- Modifying the response (injected content)
- Replacing the response (block page)

Many of them could perhaps better be solved in a different place than HTTP  
(like access point sign up through DHCP negotiated URL, MSISDN header  
enrichment through IP options etc). For the remaining ones, is the answer  
that they are supported by HTTP/2.0, or is "use HTTP/1.1 instead" an  
acceptable fallback?

/Martin Nilsson

Using Opera's revolutionary email client: http://www.opera.com/mail/
Received on Saturday, 23 June 2012 22:28:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC