[AOLSERVER] We've made a code change, would like opinions as to is this a good or bad idea...
At BNA we have a problem with use of AOLserver in terms of
how it handles the Location parameter value. The Location
is a fixed value that is a global constant for the
AOLserver process.
In our virtual hosting environment on our production
machines this a problem. The problem is as follows:
The machine host name is xyz.bna.com
One of many virtual host names is productA.bna.com
User requests http://productA.bna.com/
(notice that there is no / at the end of the user request)
According to spec AOLserver should redirect to the complete
url.
Wanted behavior is a redirect to
http://productA.bna.com//
actual behavior is a redirect to
http://xyz.bna.com//
Our location is the machine name because we can only set
one. But one location is not sufficient for our needs. I
am aware of the many different Virtual Hosting solutions
that are proposed for AOLserver. But we found a way to fix
our problem without actually needing to use any of the
currently specified Virtual Hosting approaches. I would
like to get your opinion on our approach to solving our
problem.
In nsd/return.c we have modified the function
Ns_ConnReturnRedirect. Please note the additional block of
code marked with a ZZZ BNA comment. What this does is
return the user specified host name in preference to the
Location value. This solves our particular problem. It is
not a Virtual Hosting solution per se, but it does solve our
problem.
My question is: Do any of you who know the code better than
we do think this is a dangerous thing to do? If so where
should I look in the code to see the danger? Our testing
has shown no problems with this change, at least not so far!
Here is the modified source code:
Ns_ConnReturnRedirect(Ns_Conn *conn, char *url)
{
Ns_DString ds, msg;
intresult;
char* host;
Ns_DStringInit(ds);
Ns_DStringInit(msg);
if (url != NULL) {
if (*url == '/') {
/* ZZZ BNA - we look for a host entry before
defaulting
to the location value.
*/
host = Ns_SetGet(conn-headers, Host);
if (host) {
Ns_DStringAppend(ds, http://;);
Ns_DStringAppend(ds, host);
} else {
Ns_DStringAppend(ds,
Ns_ConnLocation(conn));
}
}
Ns_DStringAppend(ds, url);
Ns_HeadersPut(conn, Location, ds.string);
Ns_DStringVarAppend(msg, A HREF=\, ds.string,
\The requested URL has moved
here./A, NULL);
result = Ns_ReturnNotice(conn, 302, Redirection,
msg.string);
} else {
result = Ns_ReturnNotice(conn, 204, No Content,
msg.string);
}
Ns_DStringFree(msg);
Ns_DStringFree(ds);
return result;
}
Thanks for the help!
/pgw
Greg Wolff
[EMAIL PROTECTED]
Re: [AOLSERVER] We've made a code change,
I'm confused. Browsers are supposed to handle relative URL redirection, so I don't understand why a relative redirect is being changed to absolute by this routine. If it were just kept relative (i.e., original code was removed instead of adding new code), then relative redirect requests could be left alone and would do what you want/expect. Jim I don't know the code well enough to comment on that aspect of it but on the idea of using the user-supplied host name in redirect I like the idea. I use a piece of tcl code that does the same thing and it's worked great for me. On Friday 07 December 2001 02:42 pm, you wrote: At BNA we have a problem with use of AOLserver in terms of how it handles the Location parameter value. The Location is a fixed value that is a global constant for the AOLserver process. ...
Re: [AOLSERVER] We've made a code change,
+-- On Dec 7, Jim Wilcoxson said: I'm confused. Browsers are supposed to handle relative URL redirection, No, they're not. Some (including IE and Mozilla, I believe) do handle relative URLs, but the HTTP/1.1 standard requires the Location header to contain an absolute URL. http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html#sec-14.30
Re: [AOLSERVER] We've made a code change,
On 2001.12.07, Jim Wilcoxson [EMAIL PROTECTED] wrote: I'm confused. Browsers are supposed to handle relative URL redirection, They are? You're right; you're confused. Perhaps browsers _do_ support relative URL redirection because so many people have foolishly violated the HTTP/0.9, HTTP/1.0 and HTTP/1.1 specifications by using relative redirections, but the HTTP/1.1 spec clearly says: 14.30 Location The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. Location = Location : absoluteURI [ From: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 ] -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] We've made a code change, would like opinions as to is this a good or bad idea...
On 2001.12.07, Peter M. Jansson [EMAIL PROTECTED] wrote: The only concern I have is a security concern I looked at security as a possibility as well and since his solution uses DStrings (which are growable, right?) then you don't have to necessarily worry about buffer overflow. However, resource starvation/denial of service is a serious potential problem. Fire up a couple hundred connections where you feed a very large Host: string ... What I would be concerned with is the fact that Greg's solution hardcodes the protocol in (http://;) which would break if the server was running HTTPS, but then you wouldn't be doing software virtual-hosting anyway, so maybe it's a moot point. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] We've made a code change, would like opinions as to is this a good or bad idea...
+-- On Dec 7, Dossy said: However, resource starvation/denial of service is a serious potential problem. Fire up a couple hundred connections where you feed a very large Host: string ... On the contrary, AOLserver limits both the size of each HTTP header line (default 8192 bytes), and the total size of all header lines (default 16384 bytes).
Re: [AOLSERVER] We've made a code change,
However, resource starvation/denial of service is a serious potential problem. Fire up a couple hundred connections where you feed a very large Host: string ... Go to any web site and hit its search engine 200 times. It will most likely die a horrible death. In fact, any routine request to a web server with 200 connections and lots of valid/longish headers will have the same problem. Just pointing out that some things are not avoidable by checking limits everywhere. I think total headers are already limited by a config directive. Jim What I would be concerned with is the fact that Greg's solution hardcodes the protocol in (http://;) which would break if the server was running HTTPS, but then you wouldn't be doing software virtual-hosting anyway, so maybe it's a moot point. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] We've made a code change, would like opinions as to is this a good or bad idea...
On 2001.12.07, Rob Mayoff [EMAIL PROTECTED] wrote: +-- On Dec 7, Dossy said: However, resource starvation/denial of service is a serious potential problem. Fire up a couple hundred connections where you feed a very large Host: string ... On the contrary, AOLserver limits both the size of each HTTP header line (default 8192 bytes), and the total size of all header lines (default 16384 bytes). So, this request: POST / HTTP/1.0 Host: 8186 bytes Content-Length: 64000 64000 of data (assuming 64kB is the MAXPOST limit, perhaps it's smaller) would use up around 72kb of data per connection (plus more for internal data structure overhead). 100 simultaneous requests would chew up around 7.5 MB, which isn't much. Perhaps there are other things one can do to really thrash a webserver that aren't specific to AOLserver itself, though. Perhaps this is a moot point. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
