>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
returned.
> b) (e.g: the CERN server) return the requested document with no
header.
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:
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".)
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
sweat.
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
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.
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