Re: Comments on HTTP draft [of 23 Nov 1994]

>> 5.3 HTTP Version: Given that this definition is more rigorous than
>>     earlier documents, and hence must be more constraining, it would
>>     seem to be necessary to change the version number (perhaps to 1.1)
>>     to reflect the stricter conditions for compliance.  If the version
>>     number is not changed, then the date of the relevant HTTP 1.0
>>     document would have to be specified at every reference.

>That is a philosophical issue that will be discussed in San Jose.
>If necessary, a subset of this spec will be assigned "HTTP/1.0" and
>work will continue on HTTP/1.1.  That decision will have to be made
>eventually, but not right away.

There is a fairly strict rule, if there is a loss of backwards compatibility
then the major version must go up. Hence HTML 2.0 because it is incompatible
in some areas with HTML 1.0.

BUT this does not imply anything about product certification ie:-

1) A server claiming to be HTTP 2.0 compliant must also be able to accept
	HTTP/1.0 requests [and HTTP/0.9 requests]
2) A client claiming to be HTTP 2.0 compliant must only generate HTTP 2.0
	requests.

The backwards compatibility requirments are:-

1) A HTTP 2.0 request must be an allowed HTTP 1.0 request

2) A valid HTTP 1.0 request must be an allowed HTTP 2.0 request

The difference between allowed and valid being that the header Foo: quark is 
allowed in HTTP 1.0 but has no meaning so is not valid.

This may at first appear to be indicating an equality but in fact it does not,
basically a HTTP 2.0 server must tolerate a HTTP 1.0 request.


I think that going to HTTP 2.0 would be a good thing, it is after all what was 
done with HTML.


I also have some comments on the BASIC authentication scheme which I will 
prepare offline together with the code. The problem is that BASIC involves 
sending passwords in the clear which is very very bad and can compromise systems 
besides those used by the party setting BASIC authorisation (dimwits sharing 
passwords between secure and insecure systems). SHTTP/SHEN is still not ready 
for release and in any case has severe legal problems. I have suggested a quick
hack that gives what I call "reasonable security" ie not on the public key level 
or distributed trust model of Shen but good enough for many applications and not 
creating security holes for other users. I'd very much like to drop this into 
the spec as soon as I've finished integrating the code into the multithreaded 
library. The wider stuff is not yet mature enough.


	Phill.

Received on Wednesday, 30 November 1994 06:05:34 UTC