Imcompatible HTTP/1.0 on different severs

chuynh@unixhub.slac.stanford.edu

Mail folder: WWW Talk Jul-Oct 1993
Next message: Marc Andreessen: "URI WG decides a couple of things"
Previous message: Ed Krol: "Re: Registrar"

Date: 14 Jul 1993 15:59:28 -0700 (PDT)
From: chuynh@unixhub.slac.stanford.edu
Subject: Imcompatible HTTP/1.0 on different severs
To: www-talk@nxoc01.cern.ch
Message-id: <9307142259.AA12619@ravel.SLAC.Stanford.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
Content-Transfer-Encoding: 7BIT
X-Mailer: ELM [version 2.3 PL11]
Status: RO

Hi,

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