- From: Roberto Peon <grmocg@gmail.com>
- Date: Thu, 21 Feb 2013 15:54:02 -0800
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNffguLnO--8SoGo2ceYTJpWut+6PuGN=p4rL84d6TvBrw@mail.gmail.com>
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 UTC