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

Re: multiplexing -- don't do it

From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Sat, 31 Mar 2012 01:12:18 +0200
Message-ID: <4F763DD2.70604@isode.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
CC: Roberto Peon <grmocg@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 31/03/2012 00:52, Adrien W. de Croy wrote:
> ------ Original Message ------
> From: "Roberto Peon" grmocg@gmail.com <mailto:grmocg@gmail.com>
>>         ·SPDY compresses HTTP headers using an LZ history based
>>         algorithm, which means that previous bytes are used to
>>         compress subsequent bytes. So any packet capture that does
>>         not include all the traffic sent over that connection will be
>>         completely opaque -- no mathematical way to decode the HTTP.
>>         Even with all the traffic, a stream decoder will be a tricky
>>         thing to build b/c packets depend on each other.
>>     I know there's a SPDY decoder plugin for Wireshark, but I'll
>>     defer to people more
>>     knowledgeable about packet analysis tools to cover that area.
>> The OP is right about this, btw. Technically it is possible that 
>> you've flushed the window after 2k of completely new data, but there 
>> is no guarantee and so interpreting a stream in the  middle may be 
>> extremely difficult.
>> Seems like a fine tradeoff for the latency savings that we get on 
>> low-BW links, though.
> I think it basically means compression or any transport level 
> transform needs to be able to be switched off when debugging.  Which 
> means optional/negotiated.
I think it should be mandatory to implement (so no discovery of the 
feature is needed), but optional to use.

> I have to analyse packet dumps of HTTP most days, as I'm sure do many 
> others on this list.  We haven't yet evolved as a species to the stage 
> where we don't make mistakes.
> I think it's a vitally important facility for discovering 
> implementation errors, which is required in many cases to resolve issues.
> Adrien
Received on Friday, 30 March 2012 23:12:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC