W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: SYN_REPLY

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 21 Feb 2013 15:54:02 -0800
Message-ID: <CAP+FsNffguLnO--8SoGo2ceYTJpWut+6PuGN=p4rL84d6TvBrw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I mean that SYN_STREAM has a priority, which is mandatory because without
it the browser won't trust the server-side to do the right thing.
SYN_REPLY doesn't have one, because it doesn't need to declare priority--
the SYN_STREAM already did that, and it is almost always a waste to include
a priority field in SYN_REPLY.

I intend to consume a flag value which indicates that the semantic-frame is
longer than the current frame. The delta code already does this. I think I
stuck that in the SPDY/4 stuff (so it could be pulled from there, unless
I'm misremembering).
-=R


On Thu, Feb 21, 2013 at 3:34 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> Yes, SYN_STREAM has the priority.
>
> The point is that if you just start using streams (as you do), then a
> stream "start" message is only necessary if there are once-only things
> to say about the stream.  By that measure, SYN_REPLY has no value.
>
> You wanted to reprioritize, so maybe you could just define PRIORITIZE.
>  A stream would optionally start with PRIORITIZE and then HEADERS.
> That would be enough.  The response could just use HEADERS.
>
> (On an tangentially related point, I don't see how we could have a
> single header with a value that spans two frames in the current
> scheme, perhaps you can keep this in mind when you propose an edit for
> delta-coding.)
>
> On 21 February 2013 15:11, Roberto Peon <grmocg@gmail.com> wrote:
> > or rather, it doesn't have one, but the former follows from this :)
> > -=R
> >
> >
> > On Thu, Feb 21, 2013 at 3:11 PM, Roberto Peon <grmocg@gmail.com> wrote:
> >>
> >> The SYN_REPLY doesn't need a priority field.
> >> -=R
> >>
> >>
> >> On Thu, Feb 21, 2013 at 3:04 PM, Martin Thomson <
> martin.thomson@gmail.com>
> >> wrote:
> >>>
> >>> I'm looking at the HTTP/2.0 streaming layer and it's not clear to me
> >>> what value SYN_REPLY adds.
> >>>
> >>> SYN_STREAM establishes priority for a stream (and that's all!).
> >>> SYN_REPLY doesn't have the power of refusal, that's what RST_STREAM is
> >>> for.
> >>>
> >>> There's no need to have a special declaration that a stream is
> >>> starting, the first message on a stream should be a clear enough
> >>> indication of that.
> >>>
> >>> It does carry headers, but HEADERS does a bang-up job of that.  In all
> >>> other respects, SYN_REPLY and HEADERS are identical.
> >>>
> >>> Do we even need the SYN_REPLY frame type?
> >>>
> >>
> >
>
Received on Thursday, 21 February 2013 23:54:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 21 February 2013 23:54:32 GMT