- From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
- Date: Thu, 14 Sep 1995 14:54:37 +0200 (MET DST)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Larry Masinter writes (in reply to me): > > Comments, alternatives, ideas? > > Yes, I don't like the interoperability problem either. If we put in > the hash-signature into HTTP/1.1, one way to avoid backward > incompatibility is to send > > accept: md5:<base64hash> > > only. HTTP/1.0 servers will reply with 300 since the only accept > header sent doesn't look like any MIME type; the client will send back > the request again with a full accept list. Clients should cache a list > of "HTTP/1.0-only" services and not try to use HTTP/1.1 features on > them. The real problem is: I have never seen a 300 response from my CERN/3.0 server. I installed /Welcome.html.en and /Welcome.html.hu When I asked for /Welcome a-l: hu, it was fine. When I asked for /Welcome a-l: en, it was fine. Asked for /Welcome with accept-language: de, and got the hungarian version in a 200 response. Asked for /Welcome with accept: text/plain, and got again the hungarian version in a 200 response. When I used netscape 1.1N, where is no a-l in request at all, as "usual", I got the hungarian version. To make sure that everithing is ok with request headers, I wrote a small echo-httpd in perl, which returns the whole request in the entity-body, and used webget -ns on the real server to see the whole responses. Next I checked the drafts again. In current draft-ietf-http-v10-spec-03.txt there is no description for 300 and 406 response codes. We shouldn't be surprised, if an 1.0 server does not respond 300 or 406. (Otherwise Roy would have put those response codes into draft.) Resume: If a client or proxy gets an "HTTP/1.0 200 ..." status-line, there is an ambiguity, wether it is really a 200, a 300 or a 406 response? Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Thursday, 14 September 1995 06:03:15 UTC