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

Re: HEADERS and flow control

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 12 May 2014 10:32:51 -0700
Message-ID: <CAP+FsNc=d+KopXH_orHYbaXaLvjwGBp2iUM1qGdo1rH_6RUZJg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Johnny Graettinger <jgraettinger@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Hasan Khalil <mian.hasan.khalil@gmail.com>, James M Snell <jasnell@gmail.com>
We are unable to express something in http2 that we previously could with
http/1 pipelining/and/or http/1.1 chunking.

That is not satisfactory.

-=R
On May 12, 2014 9:57 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

> I've been thinking about this over the weekend and I remain unmoved by
> this thread.  I think that there's a kernel of something here, but I
> remain unconvinced that this is something that we need to do anything
> about this.
>
> Basically, it's not HTTP.
>
> On 9 May 2014 17:02, Roberto Peon <grmocg@gmail.com> wrote:
> > an expression of sequencing
>
> I think that this is key.  RPC protocols often depend on some sort of
> ordering semantic in order to get decent throughput.  That and layer
> upon layer of metadata.  The protocol Roberto looks a little like
> HTTP, maybe even to the point of being a changeling [1].  I think that
> we need to discuss to what extent we want to support changelings.
>
> The alternative is that Roberto's unnamed customers need to think
> about doing option (h) and put every RPC call on its own stream, using
> header fields or some other mechanism to express dependencies [2].
> And yes, I'm aware that this isn't the only externality in play.
>
> --Martin
>
> [1] https://en.wikipedia.org/wiki/Changeling
> [2] Of course that this will cause some intermediaries to have
> non-standard hacks in them to support backends that rely on getting
> dependent streams at the same backend instance.  And that sucks, but I
> believe that to be the de facto state of these sorts of intermediary
> anyway.
>
Received on Monday, 12 May 2014 17:33:18 UTC

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