Re: Large Frame Proposal

On 2014-07-09 15:29, Jason Greene wrote:
> On Jul 8, 2014, at 10:20 PM, Jeff Pinner wrote:
> 
>>> Hey Jeff,
>>> 
>>> How is this different to you from dynamically adjusting the header 
>>> table size?
>>> 
>> 
>> I see it differently because the compressor (at least in my
>> implementation and so I realize I definitely could be biased) lives
>> above the framing codec. The low-level framer emits "header block
>> fragments" to the session processing code which then emits "header
>> fields" to the application.
> 
> Ok so, what you don’t like then is your framing layer having to
> inspect a settings frame?
> 
> If so, don’t you also have the same issue with extensions? Although I
> guess a key difference there is they are once per connection.

I don't see anything in the current draft section 5.5 that prevents a 
random extension being sent in a mid-connection SETTINGS frame. There is 
also no reason to doubt an extension coming along someday with an ON/OFF 
toggle meaning. Extensions are also explicitly defined as a way to 
permit future frame types. So things could get really, really messy for 
any implementation that completely separates SETTINGS extension handling 
from the framing layer.
  None of which has anything to do with the large frames proposal of 
course. Except to show the proposal is one of the simpler mechanisms in 
h2 if accepted.

Jeff, you also keep using this word "session". Do you mean stream? or 
connection? or are you conflating HTTP/2 with classical UA sessions 
(sets of streams)?

Amos

Received on Wednesday, 9 July 2014 04:01:38 UTC