Re: Imcompatible HTTP/1.0 on different severs

Tim Berners-Lee (
Thu, 15 Jul 93 15:43:32 +0200

>Date: 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

> document.

This was not what was intended, but I suppose as Tony
says it could be construed as a good idea. One way to
control it would be to allow www/source to represent
the source whatever it was, and to allow the client to give
that as a (very low weight) option on every request. The
same dummy content type could be used to request the
source whatever it is. This would allow clients bothered
for example by waiting for pictures they can't display
to turn it off.
If nothing matching is found, then an error should be

> b) (e.g: the CERN server) return the requested document with no

This is a deliberate bug introduced by teh -DXMOSAIC_HACK
option in the libwww. It is put in because otherwise
XMosaic would not be able to read anything except for
plain text and HTML. The MOMENT that mosaic uses HTTP2
then all servers should turn off this hack!

>2. The servers supporting HTTP/1.0 return different "Content-type:
> in the HTTP/1.0 header for the same file type.
> (e.g. BSDI server return "Content-type: image/xbitmap" for bitmap
> while HCC server return "Content-type:

Two qustions here. One is standardisation of types -- I'm
not going to talk about except to say that if MIME are
too restrictive we can *define* HTTP types to be mime
types OR http types whcih are registered separately. No

Second question is why things differ. Application/binary
(should be octet stream) is used in eth CERN server as
a default. The default, and indeed the relationship
with any file suffix, can be set up in the rule file.
You just have to keep the confiug info in your perl
and teh config info in your httpd.conf rul file

equivalent if you wnat the same results.

>3. For the servers NOT supporting HTTP/1.0, some of them ignore the
> header and treat the request as HTTP/0.9, but some do NOT ignore

> return an error message. This makes it difficult to switch over
to HTTP/1.0.

If you find a server which returns an error message you
seend mean messages to its system manager. We have
the problem with the VMS HELP gateway which we havenn't
bothered to fix... but oterwise we have fixed any we had.
Mea culpa, the bug is in a version of HTDaemon.c which
got around a bit.

Tim BL