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

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.

Received on Tuesday, 3 June 2014 23:50:38 UTC