Re: Interleaving #481 (was Re: Limiting header block size)

On 3 June 2014 23:47, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 3 June 2014 14:13, Greg Wilkins <gregw@intalio.com> wrote:
> > Yes there are current examples of some fields approaching 64KB (thanks
> > Mike), but their existence is not an argument to make the transport meta
> > channel unlimited.
>
> Actually, it is.  We've been chartered to produce a protocol that
> provides "... a new expression of HTTP's current semantics ..."  I
> understand that's it's a bit of weak-sauce to use appeal from
> authority, but I'd interpret any attempt to constrain size as a change
> to the protocol semantics.
>


Martin,

I must be making my case if you are resorting to such weak sauce:)

I think it is very weak sauce as:

   - HTTP/1 includes 413 and 414 error codes, so its semantics do support a
   limit on request entity size.  I'm only proposing to define what that limit
   is.
   - The charter calls out "misuse of the underlying transport" as a
   motivation for HTTP/2 and HTTP headers were never intended to send
   arbitrarily large amounts of application meta data.
   - The charter calls out that the specification should  "Address the
   "head of line blocking" problem in HTTP", and the current header design can
   cause head of line blocking.
   - The charter only says it is "expected to meet these goals for common
   existing deployments of HTTP", which appears to be 8KB, so that does
   give a lot of wiggle room for excluding >16KB compressed.
   - The WG has already used some wiggle room to drop existing HTTP
   semantics such as 100 and 102 responses.  I have encountered 100 responses
   many times in the wild, but very rarely have I had apps hit the 8k limit.
   - The charter allows for extensions and I am proposing an extension that
   will support the use case of arbitrary large headers/trailers etc.



> If you do manage to find a
> less-objectionable way of reaching a solution to the same problem, I
> encourage you to work through your proposal in more detail.
>

Will do and thanks for the feedback to date as I can see some of your
objections that need to be addressed (Eg big fields as well as big sets).
   Thanks also acknowledging that there is a problem here worth trying to
solve.


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.