Re: CONTINUATION was: #540: "jumbo" frames

To double up on my reply.... the uncertainly we currently have is only as a
result of applications trying to stick arbitrarily large data into the
transport meta-data channel.  Because there are real limitations on how
large transport meta-data channels can be all along a http path, such
applications are going to be hit with limits - many of which are
undisclosed and undiscoverable.

So the solution to this uncertainly is to stop encouraging applications to
put arbitrary large data into the transport meta-data channel.   The
current draft actually gives and incentive to do so!

We should be giving applications alternate channels for their meta-data.
Perhaps that is "stateless multiplexable continuations #541"? Or something
else.    Whatever, it is certainly something that is achievable and I think
it is crazy to enforce h2 to copy this drastic mistake of h1!






On 26 June 2014 21:55, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 26 June 2014 21:50, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>>
>> Didn't I already explain that it's basically impossible to remove this
>> uncertainty?
>
>
> Why?  If a path negotiates a
> please-transport-my-stupidly-large-kerberos-ticket extension, then surely
> there should some reasonable certainty that such a ticket can be
> transported over that path.
>
> For the purposes of this conversation, I don't care how the extension
> sends it, but if asked I would suggest in flow controlled data frames.
>
> regards
>
>
>
>
> --
> 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.
>



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