Re: SYN_REPLY

OK, let's do it then.

Regards,


On 27/02/2013, at 3:46 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> Great! I'm more or less OK with this (despite my minor reservations about lack of symmetry with SYN_STREAM and response in HEADERS).
> 
> Just so no one thinks I'm too crazy, I was mostly replying to this email earlier: http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0944.html. I was unclear if we had achieved consensus on that.
> 
> 
> On Tue, Feb 26, 2013 at 8:28 PM, James M Snell <jasnell@gmail.com> wrote:
> On Tue, Feb 26, 2013 at 8:16 PM, Roberto Peon <grmocg@gmail.com> wrote:
> > Ah. That explains my confusion :)
> >
> > My understanding was we would replace any reference to SYN_REPLY with
> > HEADERS (the frames are exactly the same except for the opcodes), leave
> > SYN_STREAM alone, and leave HEADERS alone.
> > That I'd support.
> >
> 
> If we're certain that all we need in the initial response frame is a
> bag of headers, then +1.
> 
> > Taking the priority out of SYN_STREAM would only bloat things on the wire,
> > since the client will always want to state priority for a new stream. I
> > don't support removing priority from SYN_STREAM.
> 
> +1
> 
> - James
> 
> >
> > -=R
> >
> >
> > On Tue, Feb 26, 2013 at 8:03 PM, William Chan (陈智昌) <willchan@chromium.org>
> > wrote:
> >>
> >> Probably my fault :) My understanding of the thread in respect to this
> >> particular point
> >> * Martin is proposing combining SYN_STREAM+SYN_REPLY+HEADERS into a single
> >> HEADERS frame.
> >>   - single HEADERS frame might contain priority
> >>   - otherwise, we need a PRIORITIZE frame
> >> * I want the initial stream frame (whether it be HEADERS or SYN_STREAM) to
> >> contain a priority.
> >> * Furthermore, I find it weird for subsequent frames carrying the header
> >> name/value block to *also* carry a priority. This is what I objected to as
> >> "tight coupling" of priority with headers name/value blocks in all
> >> HEADERS-esque frames.
> >>   - This somewhat implies we should use separate frames.
> >> * I believe Amos read my statement as arguing against stream
> >> reprioritization over its lifetime. As I've previously said on this mailing
> >> list, I am in favor of experimenting with stream reprioritization.
> >>
> >>
> >> On Tue, Feb 26, 2013 at 7:53 PM, Roberto Peon <grmocg@gmail.com> wrote:
> >>>
> >>> I'm about as clear as mud about what we're actually talking about now :)
> >>>
> >>> -=R
> >>>
> >>>
> >>> On Tue, Feb 26, 2013 at 7:49 PM, William Chan (陈智昌)
> >>> <willchan@chromium.org> wrote:
> >>>>
> >>>> On Tue, Feb 26, 2013 at 7:37 PM, Amos Jeffries <squid3@treenet.co.nz>
> >>>> wrote:
> >>>>>
> >>>>> On 27/02/2013 2:19 p.m., William Chan (陈智昌) wrote:
> >>>>>>
> >>>>>> On Tue, Feb 26, 2013 at 4:15 PM, Martin Thomson
> >>>>>> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
> >>>>>>
> >>>>>>     On 25 February 2013 20:42, William Chan (陈智昌)
> >>>>>>     <willchan@chromium.org <mailto:willchan@chromium.org>> wrote:
> >>>>>>     > Fully agreed it's more general. I think that unless we go all
> >>>>>>     the way with
> >>>>>>     > ditching SYN_STREAM too (which I disagree with), then I think
> >>>>>>     it's a net
> >>>>>>     > loss (primarily due to more difficulty in grokking the spec) to
> >>>>>>     save a frame
> >>>>>>     > type value and combine SYN_REPLY and HEADERS into one.
> >>>>>>
> >>>>>>     I'm interested in what you feel SYN_STREAM provides that you can't
> >>>>>> get
> >>>>>>     with HEADERS.
> >>>>>>
> >>>>>>     I don't care either way about whether the priority is in the
> >>>>>> message
> >>>>>>     or not.  So, in the interests of saving those few bytes, that's a
> >>>>>>     feature that could be retained (or even moved to HEADERS).
> >>>>>>
> >>>>>>
> >>>>>> I'm not completely clear here on the stated proposal, so I'll just
> >>>>>> reclarify my position here. I think that the priority should be communicated
> >>>>>> in the same frame which starts the stream, whether that frame be called
> >>>>>> SYN_STREAM or HEADERS. I'm not sure if it makes sense to continue including
> >>>>>> the priority information for followup headers, that may arrive in a HEADERS
> >>>>>> frame. I'm leaning towards saying it does not.
> >>>>>>
> >>>>>>
> >>>>>>     The only other thing is the UNIDIRECTIONAL flag.  This flag is
> >>>>>>     currently redundant: all streams sent by the client are
> >>>>>> bidirectional,
> >>>>>>     and all streams from the server are unidirectional without
> >>>>>> exception.
> >>>>>>
> >>>>>>
> >>>>>> I think in the normal HTTP use case, yes. But when you view HTTP/2 as
> >>>>>> a transport layer for other protocols, then I think it might be reasonable
> >>>>>> to have the server initiate a bidirectional stream. Currently there's no
> >>>>>> binding for that in the web platform, but you could imagine it (register an
> >>>>>> event handler for server initiated streams, rather than relying on hanging
> >>>>>> GETs / client initiated WebSockets). I don't feel strongly here due to not
> >>>>>> having a concrete use case.
> >>>>>>
> >>>>>>
> >>>>>>     As I said in another mail, I'm not sure that SYN_STREAM/SYN_REPLY
> >>>>>>     actually help with understanding the spec.  On the contrary, I
> >>>>>> think
> >>>>>>     that they lead to false impressions about how streams start.  They
> >>>>>>     imply negotiation, which is far from the case.
> >>>>>>
> >>>>>>
> >>>>>> Intriguing. I did not read the read the earlier email and that was my
> >>>>>> bad. I think I have a bias because it's always been called SYN_STREAM and
> >>>>>> SYN_REPLY and that's how I conceptualize it. I'm willing to say that my
> >>>>>> conceptions on the naming might be very biased and maybe should be
> >>>>>> discounted.
> >>>>>>
> >>>>>> In summary, here's my current position:
> >>>>>> * the first frame for a stream should include its priority (to be
> >>>>>> clear, I don't view the PUSH_PROMISE as belonging to the promised new
> >>>>>> stream, but to the associated stream)
> >>>>>> * it feels weird to me for subsequent frames on the stream that
> >>>>>> include the header name/value block to also include the priority. i don't
> >>>>>> like the tight coupling of that.
> >>>>>
> >>>>>
> >>>>> I do like it and from earlier readings I'm not alone in that. Priority
> >>>>> needs to be adaptable within the duration of the stream _in total_. Ignoring
> >>>>> the idea one end adjusting priority dynamically.... client can still name
> >>>>> its priority based on objects importance for whatever its user is doing, and
> >>>>> server claim a higher/lower relative priority based on its own knowledge of
> >>>>> the web site/service resource. There is no contradictions there and
> >>>>> adjusting the priority preference after input from both ends should not be
> >>>>> allowed to affect the traffic flow in any major way - at worst some
> >>>>> resources may get slower response time because they initially claimed lower
> >>>>> priority and raising it was rejected by the assigning algorithm.
> >>>>
> >>>>
> >>>> Just to be clear, I am very open to reprioritization, and in fact do
> >>>> want to experiment with it in HTTP/2. I'm just saying that I feel that it's
> >>>> weird to couple it to whatever frame carries the header name/value block.
> >>>> I'm trying to work through my head the implications here. I think it means
> >>>> that *if* I want to send a follow up HEADERS frame, I'd have to remember the
> >>>> priority of the stream, whereas today I calculate it once based off the
> >>>> resource type and forget it. Not a huge deal, bookkeeping's easy and the
> >>>> extra state is cheap. But it seems nice not to require it.
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> * i feel less strongly about the naming of SYN_STREAM+SYN_REPLY vs
> >>>>>> HEADERS, after what Martin wrote. i fully admit my mental bias here.
> >>>>>
> >>>>>
> >>>>> When there are two features largely duplicating the same things bias is
> >>>>> expected. :-)
> >>>>>
> >>>>> Amos
> >>>>>
> >>>>
> >>>
> >>
> >
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 27 February 2013 05:01:13 UTC