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 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:57 GMT