W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: HTTP version number

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 13 Mar 1996 23:07:17 +0100 (MET)
Message-Id: <199603132207.XAA00519@wsooti04.win.tue.nl>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Roy T. Fielding:
>[Koen Holtman:]
>> General comments on section 3.1:
>> 
>> 1) Is there any rationale for the rules in Section 3.1?  
>
>Yes. [...]

Roy, thanks for your lengthy reply, it answered many of my questions.
Nevertheless, I still have some problems with Section 3.1, I will
outline them below.

>> 2) I'm not sure that I really like the weak requirements for
>> translation by proxies that are in the draft spec now: these
>> requirements will basically shift the burden of making things
>> interoperable from proxy authors to httpd and CGI authors, and there
>> are a lot more CGI authors than proxy authors.
>
>CGI authors will have to do better than they do now in order to be
>HTTP compliant.

Yes, but will they?  Statistics show that we cannot expect too much
from the average CGI author.  Most CGI scripts that produce dynamic
content don't add an expires header, and this situation is unlikely to
improve soon.

>[...]  How the server is
>implemented is not our concern 

Yes, I agree we should not care whether script authors use CGI or some
future more advanced interface.  The point is: how much attention to
compliance from script authors, CGI script or otherwise, can we
expect?  Not much, so it would be foolish to put protocol elements in
HTTP/1.1 that require script writers to pay a lot of attention to
compliance.  If we do, the result will be lots of new `missing header
heuristics' in proxy caches.

>> 3) With proxies being allowed to upgrade and downgrade the minor
>> version number, it seems that the server, it it gets a 1.1 request,
>> will not be able to find out if there are any 1.0 applications in the
>> request chain.
>
>Yes.

I was afraid it would be yes.  I find this completely unacceptable,
because 1.0 will be an informational standard.  This means that you
can make no assumptions about a particular 1.0 feature being
implemented as described.  The 301 and 302 response codes are a good
example.

So under the current scheme, with 1.0 software in the request chain
undetectable, even if 95% of the software is 1.1, the service author
_will still have to guess_ which protocol elements can be safely used
in a response, as the response may go to some ancient 1.0 client.

>  We have talked about adding that information to Forwarded, but
>we also need to come up with a more compact encoding for that header.
>In any case, the recipient doesn't need to know about 1.0 applications
>in the request chain if there are no incompatible changes in the
>request chain applying to more than just the immediate connection.

I'm not worrying about the problem of the server interpreting the
request.  I am worrying about the problem of the server having to
generate a response that the client chain is capable of processing.

The current scheme uses the version numbers in requests and responses
to indicate capabilities of the immediate connections in the chain.
Yet, AFAIK, all the proposed 1.1 mechanisms that act on immediate
connections, like persistent connections, have their own headers to
signal capabilities, so they won't need the version numbers in the
first lines of the requests and responses.

I propose use of the version number in the request-line to indicate
the _minimal_ protocol version used in the request chain.

We can leave the Forwarded header as it is, and require that proxies
never increase the version number in a request-line that is relayed.
Proxies may however add 1.1 request headers to 1.0 requests that are
relayed to signal special capabilities like being able to do
persistent connections.

Furthermore, I propose use of the version number in the response-line
to indicate the protocol version used by the origin server.

Is this acceptable?  Both proposals are compatible to current
practice.

>> 4) So the server has to make things interoperable, but it does not
>> even know the capabilities (versions) of the software it is serving
>> to!  So, for example, if the server uses a 1.1 Cache-Control
header, >> it must always include a 1.0 Expires header.  > >Yes.
There is no way to avoid it without requiring a major protocol
>change, and thus a major version number change.

I think my above proposal is a way to avoid it.

[...]
>I would hope that the entire document gets "seriously reviewed".
>However, changing the version rules would be a mistake, since it would
>only make it easier on the protocol designers and make it harder to
>deploy implementations.

I think my proposed version rules make thinks easier, not harder.  The
rules have no disadvantages for proxy authors, but a advantage for
service authors: the server can detect whether it is talking to
software whose features are unambiguously documented in a
non-informational specification.

Under my rules, when some 95% of web software is 1.1, service authors
of complicated services that need to be very reliable can finally stop
guessing about what is actually implemented in 1.0 user agents,
because they will be able to generate a response that says `please
upgrade your software, you have to use 1.1 software if you want to use
this complicated service' for the 5% of users still using 1.0 agents.
The ability to so this is needed because service authors are sometimes
required by law or by the market place to prevent users from shooting
themselves in the foot.

> ...Roy T. Fielding

Koen.
Received on Wednesday, 13 March 1996 14:12:25 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:48 EDT