I have been experimenting with a browser implementation using HTTP/1.0, I have
found several imcompatiblities between various servers as follows:
1. The servers supporting HTTP/1.0 respond differently when accessing a document
whose type was not in the "Accept" list on the GET command. Servers eaither:
a) (e.g the BSDI server) Return the HTTP/1.0 header followed by the requested
document.
b) (e.g: the CERN server) return the requested document with no header.
Question: Should servers return the whole document even though
the client does not "Accept" that type of document? Would it be
better just to return a polite error message in a format the
client does understand?
Behaviour (a) at least seems a reasonable alternative, but (b)
seems particularly unfriendly.
2. The servers supporting HTTP/1.0 return different "Content-type: xxx/yyy"
in the HTTP/1.0 header for the same file type.
(e.g. BSDI server return "Content-type: image/xbitmap" for bitmap file
while HCC server return "Content-type: application/binary".)
I personally like the response from the
BSDI server. The "Content-type: image/xbitmap" is clearer than
"Content-type: application/binary". Also, I prefer the BSDI's return of
"Content-type: archive/xxx" and "Content-encoding: yyy" for an
archive encoded file (eg: .tar.Z) rather than the "application/octect-stream".
3. For the servers NOT supporting HTTP/1.0, some of them ignore the HTTP/1.0
header and treat the request as HTTP/0.9, but some do NOT ignore and
return an error message. This makes it difficult to switch over to HTTP/1.0.
Example of Servers ignore HTTP/1.0 header are NCSA, Indiana University, etc.
and servers do not ignore such as CCIT Arizona, Corell, etc.
4. Most of the server NOT supporting HTTP/1.0 take the HTTP/1.0 header
as an index search whenever dealing with a search.
(e.g. http://www.cis.ohio-state.edu:81/www.cis.ohio-state.edu/ultrix?
http://hoohoo.ncsa.uiuc.edu:1235/man/index )
--
Chung Huynh, SLAC, Stanford, CA.
e-mail: chuynh@unixhub.slac.stanford.edu
chuynh@ra.uvic.ca