FYI:

the From: header is a valid HTTP header. It's meant to pass the email
address of the individual on the client side to the server. The idea is
that if there are problems with the headers from the client, the server
admin can email the person listed in the From: header. It's supposed to be
used with the user's consent, but I'm pretty sure that it isn't used by
anyone (I guess this was before the Web became commercialized), and if the
From: header exists, it'll be empty.

/s.

> >
> >Jerry Asher's "vhr patch" does seem to fix this bug as well,
> >but adds extra functionality at the same time.
>
> That's an understatement!
>
> >Here's the
> >minimal patch for this problem:
> >
> >========================================================================
> ># diff -Naur nsvhr.c.orig nsvhr.c
> >--- nsvhr.c.orig        Mon Jul 30 07:45:04 2001
> >+++ nsvhr.c     Mon Jul 30 07:45:29 2001
> >@@ -339,9 +339,9 @@
> >
> >      headers = Ns_ConnHeaders(conn);
> >      host = Ns_SetIGet(headers, "Host");
> >-    Ns_StrToLower(host);
> >
> >      if (host != NULL) {
> >+        Ns_StrToLower(host);
> >         hePtr = Tcl_FindHashEntry(&map, host);
> >      }
> >========================================================================
> >
> >I'll file this in SourceForge but I'd like to know what others
> >think before I go and fix it in CVS ...
>
> I definitely think you should add this fix to SourceForge, but there is
the
> question of what should be happening when a request with no host header
> comes in.
>
> I created a "menuURL" which is similar to the errorURL, but uh, different.
>
> The idea is that no host headers would get redirected to a menuURL.
>
> I can then build (manually or however) a menuURL page that enumerates the
> hosts provided at the site and provides links COMPLETE with the nssock
> port.  This lets HTTP/1.0 hosts discover what sites are available and get
> to the site they are looking for in a friendly fashion.  This might be
done
> with the errorURL as easily, but there are errorful conditions that can
> occur in which I don't want to give the client browser a generic menu of
> sites and do want to give them a more site specific, error condition
message.
>
> At any rate, a HTTP/1.0 header should not crash nsvhr, but it's still not
> clear what you do with it after it gets to nsvhr.
>
> Jerry
> =====================================================
> Jerry Asher                       [EMAIL PROTECTED]
> 1678 Shattuck Avenue Suite 161    Tel: (510) 549-2980
> Berkeley, CA 94709                Fax: (877) 311-8688
>
>

Reply via email to