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


From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 25 Feb 2013 20:39:25 -0800
Message-ID: <CAP+FsNefW3K=H6-Ax9ip4R=VTrTECQ+943BPUBQJ=cV2jo_UMQ@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
HEADERS can be used for arbitrary other key-value metadata, in
other-than-HTTP semantic layers so it more general a name than SYN_REPLY.

It is cheap either way, and I don't care either way :)

On Mon, Feb 25, 2013 at 8:36 PM, William Chan (陈智昌)

> 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
Received on Tuesday, 26 February 2013 04:39:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC