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

OK, so I think we've descended into semantic analysis of the charter now.

I really can't see the difference between your removal of 1xx and replacing
it with a better alternative  vs my proposal of removing large application
headers from the initial request header frame and replacing it with a
better alternative (a flow controlled as infinite as you like in stream
meta data mechanism).

I also disagree that a well written HTTP/2 impl can avoid HOL blocking,
precisely because we allow unlimited non fragmentable headers.   Thus to
send a header, HTTP/2 implementations will always be at risk of hitting the
TCP/IP flow control windows and thus holding up all other streams.

Finally I don't think you have fully understood my proposal - but I guess
that is my responsibility to write it up in some more detail.   I've not
proposed disallowing arbitrarily large headers.  Large response headers can
still be transmitted with exactly HTTP semantics.   Large request headers
can still be transmitted, but with the small change that only the first set
will be considered to be part of the transport request meta data.  The
other larger headers will be available via alternate, but just not as part
of the transport request abstraction.

Now nothing is stopping the next layer up - say a servlet container,
deciding to wait until all the header sets have been received before
dispatching the request to the servlet - thus preserving the existing
semantics - it is just not mandated by the protocol that they must do this
and alternate implementation can be developed that have less memory impact
on servers and a better chance of avoiding HOL blocking.

Anyway,  I'll leave this be for a while and contemplate writing up a more
detailed proposal, but that may have to wait until we've implemented a bit
more of the existing draft.

cheers










On 4 June 2014 01:50, Martin Thomson <martin.thomson@gmail.com> wrote:

> I think that you need to find some stronger arguments than these.
>
> On 3 June 2014 15:47, Greg Wilkins <gregw@intalio.com> wrote:
> > 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.
>
> I think that Roberto addressed this.  Those are per-resource or
> per-request limits.  It's a very different proposition to change the
> entire protocol.
>
> > The charter calls out "misuse of the underlying transport" as a
> motivation
> > for HTTP/2
>
> Yeah, I'm sure that people can misuse what we provide them.  I think
> that the point is that in HTTP/1.1 you have to misuse TCP to get
> anything like a good result.  Misuse of in HTTP/2 - of the sort that
> you describe, at least - merely results in worse results.  That, for
> me, provides sufficient incentive to have users do the right thing.
>
> > and HTTP headers were never intended to send arbitrarily large
> > amounts of application meta data.
>
> That's speculative.  Though I'll concede that here we leak our
> abstraction, meaning that yes header fields are a poor choice.  But I
> couldn't categorically say that they shouldn't be used.
>
> > 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.
>
> I address this one above.  But I'll point out that HOL blocking is
> still possible: we're still using TCP.  But a good HTTP/2
> implementation on both client and server can avoid HOL blocking.  We
> don't have to make it impossible, because that is putting the perfect
> up as the enemy of the good.
>
> > 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.
>
> That's not a license to cut out all the features that only the most
> common implementations/deployments use.  HTTP has an extremely diverse
> deployment base.
>
> > 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.
>
> We removed 1xx series responses because we provided better
> alternatives for each (i.e., flow control).
>
> > The charter allows for extensions and I am proposing an extension that
> will
> > support the use case of arbitrary large headers/trailers etc.
>
> Hmm.
>



-- 
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.