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

The presence of 413, etc. does not impose a limit, actually. It simply
imposes a limit for that request.
This is quite different than an overall limit.

How would one express such a limit through a proxy, even if it were known
(it could be changing from second to second)?
Client C talks via proxy P to servers A and B. What limit would proxy P
advertise when the limits of A and B are different?

Solving these problems requires far more complexity than what exists right
now.

Common, existing deployments includes Google's properties, I'd wager to
guess. I've said a number of times that I see large responses, and that
those responses exist because of implementation deficiencies in the web
platform that are not necessarily related to HTTP.
Please don't ignore this! It would be rather difficult to attempt to
explain to the developers that *users* now have to change their behaviors
because of a protocol change that should have been transparent.

-=R


On Tue, Jun 3, 2014 at 3:47 PM, Greg Wilkins <gregw@intalio.com> wrote:

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