From owner-freebsd-bugs  Tue Jan 21 09:50:05 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id JAA02278
          for bugs-outgoing; Tue, 21 Jan 1997 09:50:05 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id JAA02270;
          Tue, 21 Jan 1997 09:50:02 -0800 (PST)
Date: Tue, 21 Jan 1997 09:50:02 -0800 (PST)
Message-Id: <199701211750.JAA02270@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Bill Fenner <fenner@parc.xerox.com>
Subject: Re: bin/2547: fetch command fail to get file
Reply-To: Bill Fenner <fenner@parc.xerox.com>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR bin/2547; it has been noted by GNATS.

From: Bill Fenner <fenner@parc.xerox.com>
To: freebsd-gnats-submit@freebsd.org, Nakai@mlab.t.u-tokyo.ac.jp
Cc:  Subject: Re: bin/2547: fetch command fail to get file
Date: Tue, 21 Jan 1997 09:38:32 PST

 This is because fetch doesn't supply an "Accept:" header, and
 Microsoft IIS appears to take the lack of an "Accept:" header
 as 'I want no types of data' instead of 'I want all types of data'.
 (The 406 error says "I don't have the type of data you want".  Unless
 the characters after the 406 are japanese, then it's probably a bug in
 IIS that prints garbage after a 406 error).
 
 Of course, RFC2068 says
 
    If no Accept header field is present, then it is assumed that the
    client accepts all media types.
 
 but we can't expect Microsloth to care.  The fix, annoying as it
 may be, is probably to make fetch say "Accept: */*" as part of its
 HTTP request.
 
   Bill