Re: Request Routing Information [was: Do we kill the "Host:" header in HTTP/2 ?]

On Mon, Feb 4, 2013 at 9:34 PM, James M Snell <jasnell@gmail.com> wrote:

>
>
>
> On Mon, Feb 4, 2013 at 9:16 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> Thanks for making concrete proposals, James -- that's helpful.
>>
>>
> No problem.. mainly just wanted to get something concrete to kick
> around...
>
>
>> [snip]
>>
>>
>> * HTTP/1.1 has two ways of serialising what we call the Effective Request
>> URI in HTTPbis, and I don't think it's too controversial to say that this
>> is bad, and in /2 we should just have one way to do it.
>>
>> * One of the HTTP/1.1 forms omits the scheme in use. Discussion so far
>> seems to imply that people want the scheme to be explicit in /2. Anyone
>> have any argument as to why not?
>>
>
> So long as we're able to minimize any redundancy caused by making this
> explicit (e.g. delta) I have no problem with this. If we can identify the
> most commonly used schemes (i'm thinking http, https and ftp really) and
> include those in the default delta dictionary, then I think we're fine. It
> becomes nothing more than just a toggl operation.
>
>
>>
>> * If we do make the scheme explicit, I'd note that HTTPbis allows use of
>> schemes other than HTTP / HTTPS, so we'd need to accommodate that. I.e., a
>> single bit is out.
>>
>> * Most people seem to see the value in separating the authority portion
>> of the URI into a separate header, because that's routed upon (and it could
>> also benefit from delta-based compression). Anyone disagree?
>>
>>
> Definitely no disagreement from me on this one.
>
>
>> * Separating the query string from the path would save the origin server
>> a bit of parsing. I see arguments on both sides; who wants to make them?
>>
>>
> Mixed feelings on this. Part of me says it's ok, another part is screaming
> at me No! Applications on the server seem to be all over the map when it
> comes to parsing and handling of request URIs. I guess I would have to just
> see what the impact of separating these would be and weigh those against
> whatever the justification is for splitting them.
>

I'm of two minds about this one as well. On one hand, it is easier for
parsing. On the other hand, I haven't done any analysis to show or disprove
that this will be better for bytes on the wire, so, while I understand some
of the cost, I don't understand all of the benfit..

-=R