Re: [AOLSERVER] Lynx/2.3 BETA crashes AOLserver 3.4 + nsvhr
At 10:54 AM 7/30/01, Dossy wrote:
>On 2001.07.30, Jerry Asher <[EMAIL PROTECTED]> wrote:
> > 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.
I guess I still haven't gotten back from camping just yet. I thought we
were discussing the case when an HTTP/1.0 header (or /.9?) without the host
field gets to nsvhr, and not the case of what happens when an HTTP/1.1
header gets to nsvhr.
According to my reading of RFC 2068, when an HTTP/1.1 header comes along
without a host field, the server MUST return a BAD REQUEST (regardless of
what makes sense to you or I)
"14.23 HOST
...
All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
status code to any HTTP/1.1 request message which lacks a Host header field."
I dunno presumably it's better to tell the user that their client isn't at
HTTP/1.1 as they might think than to do for them what you expect they
would prefer to have done. Also, why I am just completely speculating off
the top of my head now (or maybe out my *ss), I think your logic breaks
down with an HTTP/1.1 proxy request which send a proxy to a vhrish
host. There I think you would agree: send back the bad request and not the
menu url. To make the logic simpler, perhaps the protocol says HTTP/1.1 =>
supply a host field, or suffer a BAD REQUEST.
???
>Also, I don't know if anyone else has found that in order to make sure
>nsvhr works correctly, for virtual hosts on port 80, you need two
>maps:
>
>ns_param "dossy.org""http://127.0.0.1:2001";
>ns_param "dossy.org:80" "http://127.0.0.1:2001";
Yes, I've noted that before, and while it could/should be fixed in the
code, I've always just documented that. (If I recall it may be more
complex than that, I recall it's really for virtual hosts on port X where X
is the port your proxy master listens.)
Jerry
P.S. Recently, I changed how my master proxy configures it's map to make
it easier to maintain, and to open the door to one day just pulling these
maps out of a database.
In the config.tcl, I enumerate two arrays, and one proc. One array maps a
server on your site to the socket that it listens on. The other array is a
list of servers that prefer nsunix. The proc maps from a HOST field value
(name) to the SERVER that responds to that name, and then takes an optional
value to "force" the preferred protocol.
The goal is to make it easier to install new hosts, as well as to enable me
to easily switch an entire site from nsunix to/from nssock. As you can
see, the proc defines the port 80 host for you automatically, and goes so
far as to define www and web variants of any one dot host name (photo.net
gets mapped to photo.net:80 www.photo.net www.photo.net:80 web.photo.net
web.photo.net:80)
Currently (as shown below) all the hosts below are forced to using
nssock/http while I test AOLserver 3.4 versions of nsunix, etc. You can
also see that some servers will handle the requests for many different host
names. (I use Tom Jackson's VAT and other techniques for that.)
proc defserver {name aka {protocol http}} {
global server2port
if {[string equal $protocol nsunix]} {
set value unix://${aka}.nsunix
} else {
set value http://${name}:$server2port($aka)
}
set names [list $name]
set dots ""
regsub -all {[^\.]} $name "" dots
set dotcount [string length $dots]
if {$dotcount < 2} {
lappend names www.${name}
lappend names web.${name}
}
foreach n $names {
ns_param ${n} $value
ns_param ${n}:0 $value
ns_param ${n}:80 $value
}
}
array set server2port {
abattoir 4000
asher8000
hollyjerry 2000
jerrysworld 5000
photos 7000
problemsets 3000
reminder
simon
solutions9000
theashergroup3335
cvsweb 16080
downloads16080
webmail 16080
}
array set nsunix {
abattoir
asher
hollyjerry
jerrysworld
photos
problemsets
reminder
solutions
theashergroup
}
ns_section ns/server/master/module/nsvhr/maps
defserver 192.168.0.16 theashergroup
defserver 209.233.238.162 theashergroup
defserver hollyjerry.org hollyjerry
defserver abattoir.hollyjerry.org abattoir
defserver asher.hollyjerry.org asher
defserver cvsweb.theashergroup.com cvsweb http
defserver downloads.hollyjerry.org downloadshttp
defserver downloads.theashergroup.com downloadshttp
defserver webmail.theashergroup.comwebmail http
defserver webmail.hollyjerry.org webmail http
defserver jerrysworld.com jerrysworld
defserver photos.hollyjerry.orgphotos
defserver
Re: [AOLSERVER] Lynx/2.3 BETA crashes AOLserver 3.4 + nsvhr
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.origMon 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 161Tel: (510) 549-2980
> Berkeley, CA 94709Fax: (877) 311-8688
>
>
Re: [AOLSERVER] Lynx/2.3 BETA crashes AOLserver 3.4 + nsvhr
On 2001.07.30, Jerry Asher <[EMAIL PROTECTED]> wrote:
> 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.
It's perfectly clear. hePtr is NULL, which sends you to the
errorURL. And, the "Host:" request header was "optional" in
HTTP/1.0, and "required" in HTTP/1.1 -- however, your patch
looks at the HTTP request version for no good reason. If
someone's using HTTP/1.1 and doesn't supply the "Host:" header,
why not give them the menuURL anyway? What harm does it do?
+ if (conn->request->version >= 1.1) {
+Ns_Log(Debug, "nsvhr: http/1.1 bad request: host header field missi
ng");
+ Ns_ConnReturnBadRequest(conn, "Host Header Field missing");
+ }
+ else {
+ Ns_Log(Debug, "nsvhr: http/1.0 request: Host field not found, redirectin
g to menuUrl, %s", menuUrl);
+ Ns_ConnReturnRedirect(conn, menuUrl);
+ return NS_OK;
+ }
Also, I don't know if anyone else has found that in order to make sure
nsvhr works correctly, for virtual hosts on port 80, you need two
maps:
ns_param "dossy.org""http://127.0.0.1:2001";
ns_param "dossy.org:80" "http://127.0.0.1:2001";
When an HTTP request comes in for port 80, I've sometimes seen
them come in without the port designation (":80") which causes
nsvhr's hashmap lookup to come up empty. So, I just map both
possibilities and it solves the problem just fine, but perhaps
we should address this at some future point (or, document it
well).
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
Re: [AOLSERVER] Lynx/2.3 BETA crashes AOLserver 3.4 + nsvhr
>
>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.origMon 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 161Tel: (510) 549-2980
Berkeley, CA 94709Fax: (877) 311-8688
