W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Two proposals for HTTP/2.0

From: Chuck Shotton <cshotton@oac.hsc.uth.tmc.edu>
Date: Thu, 17 Nov 1994 14:40:42 -0600
Message-Id: <aaf16d930f021004ae85@[]>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> Changing the request syntax to include a full URL will preclude NEW clients
>> being able to talk to OLD servers.
>Are you really proposing that HTTP/2.0 be kept compatible with
>HTTP/1.0 such that old HTTP/1.0 servers could ignore the "HTTP/2.0" in
>the GET request and respond as if it were a HTTP/1.0 request?

Yes. This is pretty important, since most servers will handle this already.
(Most apparently ignore the HTTP/1.0 tag or don't care if the version
number is off. Try it by telnetting to port 80 and sending GET / HTTP/2.0
to any server) This means that forward/backward compatibility can be
maintained between new clients and old servers NOW, with no changes.

>Any protocol change for HTTP will have to be staged by first getting most
>of the servers to upgrade.

Only if the syntax of the request/response changes. Otherwise, the status
quo can be maintained for old servers while new clients and servers get the
benefit of new HTTP additions.

>If there are no changes proposed that
>would actually require some different response, then why bother
>calling it 'HTTP/2.0' at all?

A question of semantics, I suppose. If all that changes are the header
fields, leaving the syntax of methods, requests, and responses alone, then
there is no fundamental change required of old servers as they can just
ignore the new headers.

If radical change is a requirement for increasing the protocol version
number, then there's no reason to change the version number for this
"hostname" proposal. But if substantial functionality is added in the
context of the existing HTTP/1.0 standard, there's also no reason that it
can't be termed a new draft of the standard, or a new version altogether.
What's in a number anyway?

>Actually, this gets me to a point where I want to stop talking about
>HTTP/2.0 at *all*: we need a specification/standard for HTTP/1.0, as
>an IETF RFC, either an "informational" one or as a "draft standard".

>Is anyone willing to volunteer to put such a beast together?

There's already a draft RFC for HTTP/1.0. Were you thinking of something
beyond the current draft that's available from info.cern.ch?

Chuck Shotton                             \
Assistant Director, Academic Computing     \   "Shut up and eat your
U. of Texas Health Science Center Houston   \    vegetables!!!"
cshotton@oac.hsc.uth.tmc.edu  (713) 794-5650 \
Received on Thursday, 17 November 1994 12:42:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:10 UTC