- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 21 Feb 2013 16:31:33 -0800
- To: Roberto Peon <grmocg@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
:) SYN_STREAM would be next on the list of targets. Removing that would require a PRIORITIZE frame and (maybe) a setting to establish a default stream priority. The downside is that it would add 4 bytes to streams where a non-default priority was desired. Saving 4 bytes on the default priority might not be a good enough trade-off. For my use cases, I don't care about prioritization for most requests, so that would be a good trade-off. I'm sure that browsers are more likely to have a highly variable priority for resources, so it might be a bad trade-off. That is, if you cared more about the bits than the ability to remove another whole frame type. On 21 February 2013 16:09, Roberto Peon <grmocg@gmail.com> wrote: > Indeed, on re-reading the first message, that is what you're proposing. > > Seems reasonable to me. > -=R > > > On Thu, Feb 21, 2013 at 4:07 PM, Roberto Peon <grmocg@gmail.com> wrote: >> >> >>> > 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. >>> >>> Agree. So what does SYN_REPLY actually do then? >>> >> It contains a HEADERS block and little else. If you're arguing to elide >> SYN_REPLY given HEADERS, then sure, I can see that-- the frame fields are >> the same now that we've removed the 'in-reply-to' field. >> >> -=R > >
Received on Friday, 22 February 2013 00:32:00 UTC