Re: Imcompatible HTTP/1.0 on different severs

Tim Berners-Lee <timbl@www3.cern.ch>
Date: Thu, 15 Jul 93 15:43:32 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9307151343.AA07680@www3.cern.ch>
To: chuynh@unixhub.slac.stanford.edu
Subject: Re: Imcompatible HTTP/1.0 on different severs
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch
Status: RO
>Date: 14 Jul 1993 15:59:28 -0700 (PDT)
>From: chuynh@unixhub.slac.stanford.edu

>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