Imcompatible HTTP/1.0 on different severs
14 Jul 1993 15:59:28 -0700 (PDT)


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

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. )

Chung Huynh, SLAC, Stanford, CA.