RE: New Version Notification for draft-montenegro-httpbis-speed-mobility-02.txt

I can see why you'd want this field in the clear. But perhaps you expressed the real goal better in the minification thread:

"HTTP/2.0 should serialize (at least) these crucial fields without
gzip and preferably in a way that makes it very easy and cheap to
find them."

One way is to make the crucial fields for routing the request available in the clear. Header compression could be defined to allow leaving such fields in the clear. We'd lose the benefit of compression, though. One could replace with some hash or handle, but then we are facing the question of lifecycle for those handles as well.

Another way is what you suggest here, to reuse the stream ID and use that as a handle with the constraint you suggest. The stream lifecycle would have to be spec-ed carefully as otherwise opening up Stream IDs without clear indication as to when to reclaim them and delete the resources could be used as a DoS. HTTP's request/response pattern is an easy way to solve this. But in websockets multiplexing there is no such pattern, so perhaps we need to solve this anyways (I think ideally we should have a common or at least an aligned solution between HTTP 2.0 mux and websockets mux). There's always explicit stream (or "channel", in websockets mux) teardown. Beyond that, I guess any system can impose any limits it wants on numbers of outstanding streams open.

So yes, there are several ways to make requests easily routable in HTTP 2.0, not sure which is the best.

Gabriel

> -----Original Message-----
> From: Poul-Henning Kamp [mailto:phk@phk.freebsd.dk]
> Sent: Saturday, June 23, 2012 01:08
> To: Gabriel Montenegro
> Cc: Rob Trace; ietf-http-wg@w3.org
> Subject: Re: New Version Notification for draft-montenegro-httpbis-speed-
> mobility-02.txt
> 
> In message
> <CA566BAEAD6B3F4E8B5C5C4F61710C1148057DA6@TK5EX14MBXW602.w
> ingroup.wi
> ndeploy.ntdev.microsoft.com>, Gabriel Montenegro writes:
> 
> >I'm a bit confused by your proposed tweak:
> >
> >> 	Once created, all requests on a given stream MUST have the
> >> 	same "Host:" header.
> >
> >Currently, we don't reuse streams, so the assumption is that a request
> creates
> >one and a reply tears it down.
> 
> OK, I don't know how I could have missed that bit.
> 
> I think that is a bad idea, it adds a lot of overhead-processing that
> can be trivially be avoided by reusing the stream in the restricted way
> I propose.
> 
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by
> incompetence.

Received on Monday, 25 June 2012 20:02:52 UTC