Re: SYN_REPLY

It's kinda nice when reading the spec to have a symmetric
SYN_STREAM&SYN_REPLY. Is there a reason to prefer the HEADERS name over the
SYN_REPLY name? One main use case with HEADERS was for server push, but now
that we're opting to use a PUSH_PROMISE frame rather than a SYN_STREAM as
our "promise", we don't need HEADERS since we'll just send a SYN_STREAM
when we need it.

How important is supporting stuff like chunked extension headers and http
trailers? I guess we need to support it for backwards compatibility reasons
with HTTP/1.X? I guess if we need that, then a HEADERS name might be more
"general", but it is somewhat hurtful for the common case where all the
headers come back in a single reply.

If no one has other comments about this, then don't worry about my concerns
and move forward anyways. I'm more lamenting the assymetry of SYN_STREAM
and HEADERS. I suspect it'll confuse people. Honestly, despite the
"wastefulness" of a frame type, maybe it's better for clarity's sake to
burn a frame type (they're cheap). I think the code cost is cheap too.


On Thu, Feb 21, 2013 at 4:09 PM, 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
>>
>
>