In message <A90E6D81-FA41-4316-8650-5CB16158AE76@mnot.net>, Mark Nottingham wri
tes:
>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
better.
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:
Host:
URI suffix (".jpg" vs. ".html")
Session(-cookies)
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.