- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Tue, 03 Dec 1996 11:17:55 -0800
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: Dave Kristol <dmk@research.bell-labs.com>, Steve Wingard <swingard@spyglass.com>
>>2) Send HTTP/1.1 responses always.
>>
>> Pro: the server advertises its capability
>> Con: because the response (headers) must be HTTP/1.0
>> compatible, the server is "lying" about the kind of
>> response and may mislead or confuse the client.
>>
>>My preference is (1).
>>Dave Kristol
I don't believe this Con. There is no lie in using a portion of the
HTTP/1.1 protocol. There is no need to use every feature on every
response.
Steve asked:
> We've been working with implementation #2 (taking care not to use
> any 1.1 mechanisms that would cause problems to a 1.0 client when
> the request indicates HTTP/1.0), and have not encountered any
> interoperability issues yet. I've noticed that www.apache.org is running
> a preliminary version of Apache v1.2 that returns HTTP/1.1 in its
> responses -- Robert, have you folks gotten any complaints from
> any users?
We had one mention from a user of an obscure Fresco browser that it
puked on receipt of "HTTP/1.1 200 ...". It was (and is) my opinion that
it is better to kill a client that is that poorly implemented now rather
than let it fester. We have had no other complaints.
The only real problem we have encountered is with the poor user interface
given to browsers with settings for the language tag. It seems that
several major browsers encourage the user to send "en-US" instead of
just "en" (or "en, en-US"). This is causing havoc with the language
selection algorithm. However, this is not specific to HTTP/1.1.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92697-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Tuesday, 3 December 1996 11:47:33 UTC