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/
