htaccess "Redirect" problem?

[nutz]

Hi,

I am trying out the LiteSpeed server (3.3.4 standard on Linux), and generally liking it very much! But I think I may have found a bug in the .htaccess "Redirect" directive processing when the original URL exists.

For example, it will fail to redirect with this entry if "dir" exists on the server:

Redirect /dir/ http://otherserver.com/dir/

But it will work if it is changed to a "RedirectMatch":

RedirectMatch /dir/(.*) http://otherserver.com/dir/$1

The redirect also seems to be fine if it is set in the control panel (Context) instead. So it looks like the problem is something specific to the .htaccess "Redirect" processing.

Let me know if you need any additional information.

 

[mistwang]

Thanks for the bug report.
Yes, the case you described does exist, as it is ambiguous when LSWS map a URI to file system, right now, LSWS give the real directory higher priority. we will think about a solution, but it is low priority as there are work arounds available.

 

[nutz]

OK, thanks for the confirmation.

Is "RedirectMatch" much slower to process than "Redirect"? If not, I guess you could just internally translate "Redirect" to "RedirectMatch" for a simple fix.

I think I may have found a similar bug with the "RewriteEngine" processing. For example, consider the following rule to redirect "fileX" to "file1" when there is a referrer:

RewriteCond %{HTTP_REFERER} .+
RewriteCond %{REQUEST_URI} !^/dir/file1$
RewriteRule ^dir/file.$ /dir/file1 [R,L]

If there is also a "Context" setup for "dir" then this rule will not work in .htaccess, but it will work if it is set in the "Rewrite" control panel instead (with "/" added before "dir" in the "RewriteRule").

Although the control panel route provides a workaround, if at all possible, I would prefer to use .htaccess for this sort of thing as it is then simpler to transfer between servers.

Btw, I am getting a lot of "The connection was reset" messages when I try to open pages here, and I have to wait a while before I can successfully open another page. For example, if I try to preview my post, I then have to wait before I can post it. I guess I am being locked out by the server due to its "Per Client Throttling" settings? I think I have a fairly standard Firefox 2 installation, without any download accelerators or anything like that, so I am not sure why this is happening. Do you have any ideas? Are the "Per Client Throttling" settings quite tight here?

Thanks.

 

[mistwang]

Btw, I am getting a lot of "The connection was reset" messages when I try to open pages here, and I have to wait a while before I can successfully open another page. For example, if I try to preview my post, I then have to wait before I can post it. I guess I am being locked out by the server due to its "Per Client Throttling" settings? I think I have a fairly standard Firefox 2 installation, without any download accelerators or anything like that, so I am not sure why this is happening. Do you have any ideas? Are the "Per Client Throttling" settings quite tight here?

We have been tuning our setup to fend off a DoS attack since Netcraft mentioned LiteSpeed in its latest web server market share report.

It is really a shame to the one who attacking us. they should try to improve the quality and performance of Apache, instead of trying to bring down our web site.

 

[nutz]

Apache are attacking you?! If so, that is indeed a shame.

I have found the trigger of my "The connection was reset" problems now. Firefox's maximum persistent connections had been set to 22. I guess I must have done that when testing something at some point

I have noticed a few more little bugs:

The 301 and 302 status pages show "%s" in place of the redirection URL (maybe a "strcpy" instead of a "sprintf"). Also, custom 301 and 302 pages are not used.

It seems that regardless of the "Max Keep-Alive Requests" and "Keep-Alive Timeout" settings, the header is always "Keep-Alive: timeout=5, max=100".

 

[mistwang]

I have noticed a few more little bugs:

The 301 and 302 status pages show "%s" in place of the redirection URL (maybe a "strcpy" instead of a "sprintf"). Also, custom 301 and 302 pages are not used.

It seems that regardless of the "Max Keep-Alive Requests" and "Keep-Alive Timeout" settings, the header is always "Keep-Alive: timeout=5, max=100".

Thanks, we aware of it. Low priority and won't really affect anything.