Re: Large Frame Proposal

Thanks, Greg.

I'm very much of two minds about this proposal.

On the one hand, it's very late in the process; if these issues and this proposal had been articulated six or even three months ago, we'd be having a very different conversation. We committed at our recent meeting to go to WGLC on a tight schedule, and it's not at all certain that such an invasive change is necessary to resolve the underlying issues. As such, I suspect implementer enthusiasm is going to be dim (and yes, I saw the attempt to address this in the write-up).

On the other hand, it is a very interesting proposal, and it does seem to address many potential objections as well as the underlying issues. As such, I want to see the Working Group take it seriously; we cannot simply ignore it, if only because doing so is very likely to get us an even larger delay in our LCs and beyond.

I'm currently discussing this with our AD to make sure we get the balance right.

Stepping back, I'll make one observation -- we're seeing a lot of proposals, and I think the underlying issues are still muddy. I've tried to separate them out in the issues list; see:
   https://github.com/http2/http2-spec/issues/549
   https://github.com/http2/http2-spec/issues/550
   https://github.com/http2/http2-spec/issues/551

If we can't gain consensus one of our current proposals, we're still going to need to have good answers for each of these issues.

Regards,

P.S. I suspect that the relative silence from many over the last few days is due to the US long weekend; welcome back,and please get into the discussion ASAP.


On 7 Jul 2014, at 6:39 pm, Greg Wilkins <gregw@intalio.com> wrote:

> 
> 
> 
> On 7 July 2014 18:27, Mark Nottingham <mnot@mnot.net> wrote:
> Hi Greg (et al),
> 
> Thanks for the proposal. The most immediate concern I have here is how SETTINGS is used; see my recent e-mail to Jason.
> 
> 
> Mark,
> 
> In reference to your comment:
> 
> > SETTINGS is explicitly not a negotiation mechanism; it only allows one end to advertise its configuration to its peer.
> >
> > In this case, the semantic of MHS (MAX_HEADER_SIZE) would be roughly "I allow headers 
> > coming at me to be at most THIS BIG." There's no way for the peer to ask for more; it has to 
> > accept the limitation.
>  
> Correct!  This is not intended to be a negotiation, it is simply intended to make explicit the current HTTP semantics that allows a server to reject large entities.    It is not an invitation to haggle with an endpoint, the endpoint is simply saying - don't even think about sending me a header larger than this setting.
> 
> Endpoint already have limitation, which can only be discovered by attempting to send a header block, only to receive a 413.  This proposal puts the burden on the sender rather than the receiver to enforce such limitations.
> 
> cheers
> 
> 
> 
> 
> 
> 
> -- 
> Greg Wilkins <gregw@intalio.com> 
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
> http://www.webtide.com  advice and support for jetty and cometd.

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 7 July 2014 10:13:14 UTC