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

Re: Adjusting our spec names

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sat, 31 Mar 2012 12:13:38 +0000
To: Mark Nottingham <mnot@mnot.net>
cc: Willy Tarreau <w@1wt.eu>, "<ietf-http-wg@w3.org> Group" <ietf-http-wg@w3.org>
Message-ID: <2493.1333196018@critter.freebsd.dk>
In message <A90E6D81-FA41-4316-8650-5CB16158AE76@mnot.net>, Mark Nottingham wri

>We can discuss the problem of date generation/parsing. In a 2.0-only 
>chain, it would indeed be nice if we could dispense with this altogether 
>(e.g., with a separate set of headers to replace 
>date/last-modified/expires that get transformed to them on a 1.x hop 
>only). Let's discuss that.

Yes, we absolutely need to do that.

But there are things we should think about before that, such as

"Why do we even need a Date: header in the first place" ?

It's not like we're talking store-and-forward messaging...

My preference for how to shape the WG progress, would be to set up
a number of straw-man scenarios, and work through them to understand
where it is HTTP/1.1 come up short, and what HTTP/2.0 needs to do

For example, if one of the strawmen is "1 Tb/s HTTP served on
a single IP#" we will probably end up with an analysis like:

	The first thing our incoming requests sees is a
	load-balancer/director gadget, which would much more precisely
	be named a "HTTP-router"

	Typically requests are distributed to backend HTTP servers
	based on relatively crude metrics, typically:

		URI suffix (".jpg" vs. ".html")
		Extrinsic information (server load, etc.)

	While compression in general is a desirable thing, there
	may be a compelling argument for at least making it possible
	to avoid/prevent compression of these "envelope-fields" in
	order to reduce the amount of work a http-router has to do.

	The parallels to flow-routing should certainly be explored,
	in particular with respect to a session-concept that doesn't
	rely on cookies.

Ohh, so having a robust session-mechanism is important at the
second-lowest level of HTTP transport ?

Hmm, maybe we should pay some attention to that, rather than have
people kludge it with cookies.

And so on...

HTTP/2.0 needs to be a visionary standard, otherwise we'll just
be slowing down progress.

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 Saturday, 31 March 2012 12:14:03 UTC

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