Re: multiplexing -- don't do it


------ Original Message ------
From: "Alexey Melnikov" <alexey.melnikov@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>
Sent: 31/03/2012 12:12:18 p.m.
Subject: Re: multiplexing -- don't do it
>On 31/03/2012 00:52, Adrien W. de Croy wrote:  
>>
>>------ Original Message ------
>>From: "Roberto Peon" 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. 
for something like TLS or gzip I've absolutely no problem with that. 
  
>
>>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:20:01 UTC