>
>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
