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

RE: HTTP Header Compaction Results

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Tue, 23 Oct 2012 16:00:43 +0000
To: Roberto Peon <grmocg@gmail.com>, Martin Nilsson <nilsson@opera.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E522F5D3@ADELE.crf.canon.fr>
Roberto,

> -----Original Message-----
> From: Roberto Peon [mailto:grmocg@gmail.com]
> Sent: mardi 23 octobre 2012 17:29
> To: Martin Nilsson
> Cc: ietf-http-wg@w3.org
> Subject: Re: HTTP Header Compaction Results
> 
> What Martin said... with special emphasis on the difficulty of sanitizing the
> headers. :)

I've found very strange things in the response headers from our testing corpus. :-)

> 
> The other complication is that we want to see what an entire interaction
> looks like (for compression), and not just the initial page load (unless that is
> how the users typically interact with that site)

On this point, we are testing both the initial page load and longer sessions where the user loads several pages from the same site. The number of loaded pages clearly has a strong effect on the compaction results.

Hervé.

> 
> 
> -=R
> 
> On Oct 23, 2012 12:57 AM, "Martin Nilsson" <nilsson@opera.com> wrote:
> 
> 
> 	On Mon, 22 Oct 2012 18:36:40 +0200, Vinayak Hegde
> <vinayakh@gmail.com> wrote:
> 
> 
> 
> 
> 			We are wondering whether anyone is aware of a test
> corpus for HTTP exchanges that would be available, or could be made
> available. This would help us obtaining fair and realistic results.
> 
> 
> 
> 		The internet archive stores the HTTP response as it is
> received and
> 		has a huge trove of results. However I don't know if it is
> available
> 		for download and replay. The arc file format is documented
> here -
> 
> 	http://crawler.archive.org/articles/developer_manual/arcs.html
> <http://crawler.archive.org/articles/developer_manual/arcs.html>
> 
> 
> 
> 
> 	As discussed previously, the headers in the HTTP request may be
> more relevant to compress, since you want to fit as many requests as
> possible in the initial TCP window. In the response the headers are many
> times dwarfed by the size of the actual resource. Getting a representative
> sample for test purposes quickly gets difficult for privacy reasons, in
> particular if you capture mobile traffic, where unique identifiers like phone
> number could be added to the requests by the network operator.
> 
> 	/Martin Nilsson
> 
> 	--
> 	Using Opera's revolutionary email client:
> http://www.opera.com/mail/
> 
> 
Received on Tuesday, 23 October 2012 16:02:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 October 2012 16:02:16 GMT