W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 26 Jun 2014 14:41:19 -0700
Message-ID: <CAP+FsNe2yOuDr6gOJQMEqNFV7J4tZcJ87uT5AtTpvtG-MzNKBQ@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, HTTP Working Group <ietf-http-wg@w3.org>
Today the use of CONTINUATION does not imply header block > 16k.
So be careful what you're considering "evil", and why :)

-=R


On Thu, Jun 26, 2014 at 1:01 PM, Greg Wilkins <gregw@intalio.com> wrote:

> 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.
>
Received on Thursday, 26 June 2014 21:41:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC