httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject this host crap
Date Wed, 24 Apr 1996 20:37:31 GMT

is mighty interesting.  Some of the bizarre Host: headers I've been sent:

  (okay, not that bizarre, but a reminder that we need to account for 
  (a reminder that we need to deal with port #'s - I'd prefer to in this 
  case sent back a 302 Location: (or is it 303?) removing the redundant 
  :80 URL)

  (a reminder that it looks like we'll have to handle ending-periods too)

Truely fucked up:

   (sent by "NCSA_Mosaic/2.7b3 (X11;meson 4_52 mips)" and 
   "NCSA_Mosaic/2.7b3 (X11;krypton 4_52 mips)" when accessing, all coming from

   (is this legal?)
   (this is coming from a lot of different UA's and hosts, all the UA's 
   have "via proxy gateway  CERN-HTTPD/3.0 libwww/2.17" attached, I 
   suppose the CERN proxy has a problem with "", 

  (previously noted, I'm working with Dean on this one.)


  These are the most bizarre.  The actual logfile entries claim they are 
  coming from "" and "" respectively, 
  and they appear to be robotic in nature, yet they have the User-Agent 
  set to valid Mozilla user-agents (like Mozilla/3.0b2 (X11; I; Linux 
  1.3.94 i586), sometimes i486)) sometimes going via a proxy server, 
  sometimes not.  I'm almost wondering if this is a bug of some sort - 
  I've sent mail to Mark and to the .tw mirror maintainer (this is a 
  mirror I had not been informed of, and isn't on our pages yet) to see 
  if it's really from them, or if some sort of corruption from the 
  Referer: field is coming in somehow.

  Apparently the cache at (which doesn't appear to 
  identify itself in the user-agent header, maybe it does in the 
  Forwarded: header, I don't know) decided to add a "Host:".  The browser which sent this was NCSA_Mosaic/2.7b3 (X11;IRIX 5.3 IP19)
  Maybe it was the browser, but I saw lots of other NCSA_Mosaic/2.7b3 
  X11's which appeared to handle proxies without a problem. No, wait - 
  this was also the cause of another bogus Host: header, "fgw".  I 
  haven't seen any requests from NCSA_Mosaic/2.7b4 through a proxy yet, so
  maybe this is a bug in XMosaic.  You folks at NCSA want to look at this?

  Okay, so both "Mozilla/2.01Gold (Win95; I)" and "Mozilla/2.0 
  (Macintosh; I; 68K)" sent this erroneously - the URL in these cases was 
  (get ready)


  This is a protected service so I can't see what type of response these 
  people really got - both requests came from "".  Maybe 
  Netscape 2.0 doesn't change the value of the Host: header after a 302 
  or 303 redirect?

  6 bogus requests were made, all from the same remote host and with the same
  client (Mozilla/2.0 (Win16; I)), with the referer being
  "".  Looking at that 
  page, there are references to hyperreal in addition to lots of other 
  places, but I don't see anything that should explicitly trigger such a 
  bogus request.  

>From all of these, I get the feeling that handling bogus Host: headers is 
going to be an interesting situation.  Since the migration path will not 
be smooth, one option I'd like to have is to be able to, on the absence 
of a Host: header or the existance of a bogus one, return an error, 
something like "Malformed Request".  Roy will no doubt have opinions on 
this.  :)

Forward where appropriate.


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--  |  We're hiring!

View raw message