nested ErrorDocuments not working

[aww]

I just realized that nested ErrorDocuments are not working in my older 3.1.1 copy (I will have to wait until a lighter load overnight to upgrade to the 3.1.1 final release but this might be wrong in both)

ie.

/public_html/missing-example.html can have one errordocument in htaccess

/public_html/images/missing-image.jpg could be a lower level .htaccess in images overriding the one above it

Works perfectly in apache. Not in LiteSpeed. LiteSpeed shows the top ErrorDocument. Actually, possibly the LAST errordocument for that error code it processed.

ie.
/.htaccess
/images/.htaccess
/blog/.htaccess

The errordocument for 404 in /blog/ will be shown if a 404 occurs in /images/ or /

At least in my working server. You might want to test this on 3.1.1 production, otherwise I will also test it on the latest tonight.

[mistwang]

It works fine in lab environment, maybe it is caused by something else.

[aww]

Well I am experiencing ErrorDocument issues.

1. Upgraded to 3.1.1 final release

2. Created a brand new fresh account under cpanel called "demosite"

3. made a test document index.html

4. http://ipaddress/~demosite/index.html
works as expected

5. http://ipaddress/~demosite/blahblahblah
gives proper litespeed generic 404 page

6. create and upload .htaccess with single line:
ErrorDocument 404 "missing

7. http://ipaddress/~demosite/blahblahblah
server thinks about it for a few seconds and then times out with a blank page - view source shows it's blank

note this step on apache with same httpd.conf & .htaccess produces proper "missing" message

[aww]

I've traced the additional nested htaccess errordocument issues to litespeed being overly aggressive on rewrite issues in the topmost .htaccess

however the issue is so complex that I am having difficultly producing a simple example - will have to work on it - note that the issues do not exist when apache is running, it interprets the nested rules perfectly

[mistwang]

Well I am experiencing ErrorDocument issues.
7. http://ipaddress/~demosite/blahblahblah (http://ipaddress/%7Edemosite/blahblahblah)
server thinks about it for a few seconds and then times out with a blank page - view source shows it's blank

note this step on apache with same httpd.conf & .htaccess produces proper "missing" message

Can you turn on the debug logging by set "DEBUG Level" to "HIGH", then reproduce it. Please post the related log entries by greping your IP.

[mistwang]

I've traced the additional nested htaccess errordocument issues to litespeed being overly aggressive on rewrite issues in the topmost .htaccess

however the issue is so complex that I am having difficultly producing a simple example - will have to work on it - note that the issues do not exist when apache is running, it interprets the nested rules perfectly
You can try turning on rewrite log by adding Apache directive "RewriteLogLevel 9" to the section of this vhost in your Apache httpd.conf. Send me the rewrite log and tell me which rewrite rule has been over processed along with the rewrite rules in your .htaccess files.

[aww]

Okay here's the problem in how apache processes a certain rule differently than litespeed - it might be difficult for you to setup a test environment, though maybe you can do a quick wordpress install

/~demosite has a blog installed in /~demosite/blog/

To keep all the htaccess rules in the top-most directory, this is perfectly acceptable in apache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog
RewriteCond %{REQUEST_FILENAME} ^/home/demosite/public_html/blog/.*$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>

However litespeed does not like this.
For litespeed, these rules MUST be in .htaccess in /blog/ not /

I have no idea why. But again, works in apache, not in litespeed

This is what was messing up all the 404 error documents (except for the 404 "missing" which still does not work)

Last but not least there is also a very minor issue in how litespeed treats:

/~demosite/images/ as a 404 missing error, when it should be a 403 forbidden error because of -Indexes in a top-most .htaccess (or httpd.conf) This is trivial however compared to the other issue.

[aww]

Per your debug log request for the blank 404 "missing"


2007-05-16 03:43:18.772 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] New request:
Method=[GET], URI=[/~demosite/fdgksdjfgsdfh5554],
QueryString=[]
Content Length=0
2007-05-16 03:43:18.772 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] Find context with URI: [/], location: [/usr/local/apache/htdocs/]
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] redirect to:
URI=[/fdgksdjfgsdfh5554],
QueryString=[]
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] Find context with URI: [/], location: [/home/demosite/public_html/]
2007-05-16 03:43:18.773 [DEBUG] [HTAccess] Updating configuration file [/home/demosite/public_html/.htaccess]
2007-05-16 03:43:18.773 [INFO] [HTAccess] Updating configuration from [/home/demosite/public_html/.htaccess]
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] Find .htaccess context with URI: [/], location: [/home/demosite/public_html/]
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] File not found [/home/demosite/public_html/fdgksdjfgsdfh5554]
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] processContextPath() return 25
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] processNewReq() return 25.
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] HttpConnection::sendHttpError(),code=404 Not Found
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] HttpConnection::flush()!
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] Written to client: 1373
2007-05-16 03:43:18.773 [DEBUG] [123.123.123.123:63893-0#APVH_server.example.net] HttpConnection::nextRequest()!
2007-05-16 03:43:22.111 [DEBUG] Failed to execute 'mpstat' command: No such file or directory
2007-05-16 03:43:23.772 [DEBUG] [123.123.123.123:63893-1] Keep-alive timeout, close!
2007-05-16 03:43:23.772 [DEBUG] [123.123.123.123:63893-1] Close socket ...
2007-05-16 03:43:27.117 [DEBUG] Failed to execute 'mpstat' command: No such file or directory
2007-05-16 03:43:32.120 [DEBUG] Failed to execute 'mpstat' command: No such file or directory

[aww]

LiteSpeed supports the QSA option on rewrites, correct?

[mistwang]

LiteSpeed supports the QSA option on rewrites, correct?
yes, it is implemented.

[aww]

Was the debug log of any help at all?

[mistwang]

The log shows that the custom error page has been delivered.
What browser are you using?
Can you try somthing with "lynx"
lynx -mime_header http://....
Please post the result.

[mistwang]

I built a 3.1.2 package for you with the fix to your rewrite rule. Just change the release number to 3.1.2 in the download link to get it.
Thank you for raising this issue, our target is to make our rewrite engine 100% compatible with Apache's, no matter is better or worse.

It is better to put all blog related rules under blog/ directory for better performance, the rewrite condition RewriteCond %{REQUEST_FILENAME} ^/home/demosite/public_html/blog/.*$ can be removed, and only requests to /blog/... will go through those rewrite rules. Just a recommendation.

[aww]

Thank you for the quick fix. I will give this a test in about eight hours as I have to wait for server activity to go down.

I assume you are able to reproduce this as I am dealing with a very complex set of rewrite rules and sometimes its hard to be sure they are all working at once without conflicting with each other and that it's not my own fault for a bad rule.

It helps though that I am able to stop lsws and start httpd within a few seconds of each other to test compatibility however.

On that note, keep in mind that apache DOES return the "missing" message on ErrorDocument with the same httpd.conf/htaccess however I will also give it a try with a raw browser tool I have like lynx - will post in a few minutes.

[aww]

Response via litespeed:
05/16/07 13:53:04 Browsing http://example.net/blahblah123
Fetching http://example.net/blahblah123 ...
GET /blahblah123 HTTP/1.1

Host: example.net

Connection: close

User-Agent: Mozilla/5.0 (WinNT)



HTTP/1.1 404 Not Found

Date: Wed, 16 May 2007 17:53:08 GMT

Server: LiteSpeed

Connection: close

Content-Length: 8

Content-Type: text/html


response via apache:

05/16/07 13:57:03 Browsing
http://example.net/blahblah123
Fetching http://example.net/blahblah123 ...
GET /blahblah123 HTTP/1.1

Host: example.net

Connection: close

User-Agent: Mozilla/5.0 (WinNT)



HTTP/1.1 404 Not Found

Date: Wed, 16 May 2007 17:57:03 GMT

Server: Apache

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=iso-8859-1



8

missing"

0



By the way, I have no idea what that 8 and 0 is before and after the apache ErrorDocument text is.

Is it part of the "chunked encoded" process where it's a segment of sorts?
Ah it might be the content-length for that segment of the chunked output.

Apparently I also accidentally left an end quote on the the "missing" when it should be just "missing - but I doubt that is what is messing up lsws right?

So is apache getting around the issue by using chunked output.
I notice apache also appends a charset, though nothing is specified in my htaccess, must be in httpd or some kind of default. Is it not important for litespeed to mimic that behavior? Will litespeed obey if I add this to htaccess?
AddDefaultCharset iso-8859-1

[aww]

Nope, there's another one for your compatibility list:

AddDefaultCharset
does not appear to be supported.
http://httpd.apache.org/docs/1.3/mod/core.html#adddefaultcharset

Seems alot of people say it's bad technique to use it, but I figure you should at least support it.

[aww]

Oh I just discovered something even worse with errordocument.
Under a http 1.0 request it's not supported at all:


05/16/07 14:23:54 Browsing http://example.net/blahblah123
Fetching http://example.net/blahblah123 ...
GET /example.net/blahblah123 HTTP/1.0

User-Agent: Mozilla/5.0 (WinNT)



HTTP/1.0 404 Not Found

Date: Wed, 16 May 2007 18:23:53 GMT

Server: LiteSpeed

Connection: close

Cache-Control: private, no-cache, max-age=0

Pragma: no-cache

Content-Type: text/html

Content-Length: 390



<html>
<head><title> 404 Not Found

</title></head>
<body><h1> 404 Not Found

</h1>
The resource requested could not be found on this server!<hr />
Powered By <a href='http://www.litespeedtech.com'>LiteSpeed Web Server</a><br />
<font face="Verdana, Arial, Helvetica" size=-1>Lite Speed Technologies is not responsible for administration and contents of this web site!</font></body></html>

[mistwang]

LSWS does not treat HTTP/1.0 or 1.1 differently on this matter. Have you changed any configuration?

What testing tool are you using?
You should redirect the result to a file, as the last line of LiteSpeed output is too short, just "missing", without "\n", so it was overwritten by the command line prompt. It is there, just not visible from command line.

I think the issue you experienced is browser related. Have you tried it with other browsers?

[aww]

I just tried the http 1.1 vs http 1.0 on the clean demosite account I had made under cpanel

LiteSpeed is definitely returning it's default 404 error page under HTTP 1.0 when there is an ErrorDocument present in htaccess

I will do a test with CURL to capture the exact http stream for 1.1 and 1.0

I have tested this in IE/Firefox/Opera - all fail the errordocument.

If you are getting different results on your test setup, then obviously this is a httpd.conf issue with the default cpanel setup I have, or possibly some option I have turned on inside LiteSpeed's config ?

[aww]

Update, http 1.0 does work like 1.1 sorry about that.
It's my stupid program that isn't handling the ~ correctly.


But there is still an errordocument problem.

[aww]

Watching what wget does with -d -v is interesting:



---request begin---
GET /~demosite/fdgksdjfgsdfh5554 HTTP/1.0
User-Agent: Wget/1.10.2 (Red Hat modified)
Accept: */*
Host: 123.123.123.123
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.0 404 Not Found
Date: Wed, 16 May 2007 19:41:23 GMT
Server: LiteSpeed
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Content-Length: 7
Content-Type: text/html---response end---
404 Not Found
Registered socket 3 for persistent reuse.
Skipping 7 bytes of body: [] aborting (EOF received).
Disabling further reuse of socket 3.
Closed fd 3
15:41:28 ERROR 404: Not Found.


Skipping 7 bytes of body: [] aborting (EOF received).

compare that to what apache does:

---request begin---
GET /~demosite/fdgksdjfgsdfh5554 HTTP/1.0
User-Agent: Wget/1.10.2 (Red Hat modified)
Accept: */*
Host: 123.123.123.123
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 404 Not Found
Date: Wed, 16 May 2007 19:49:07 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

---response end---
404 Not Found
Closed fd 3
15:49:07 ERROR 404: Not Found.


Now why apache is sending back a HTTP 1.1 response
when there is a clearly a 1.0 request is just weird. But that EOF is weird too.

[aww]

Oh I'm sorry I totally missed I can just do this from console with lynx like you said:

This stuff is just wierd:

lynx -mime_header http://123.123.123.123/~demosite/fdgksdjfgsdfh5554
HTTP/1.0 404 Not Found
Date: Wed, 16 May 2007 20:06:13 GMT
Server: LiteSpeed
Connection: close
Content-Length: 7
Content-Type: text/html[%s] HttpConnection::onReadEx(), state: %d![%s] readToHeaderBuf() return %d. [%s] processNewReq() return %d. [%s] HttpConnection::flush()![%s] m_pHandler->onWrite() return %d
[%s] Handler write error, CLOSING![%s] redirect status code: %d[%s] Request has not been logged into access log, response body sent: %ld!int HttpConnection::writeRespBodyv(IOVec &, int)m_pChunkOS == __null[%s] Keep-alive timeout, close![%s] Connections over flow, close connection![%s] Connections is over the limit, close![%s] Shutdown time out![%s] Oops! POLLIN is turned off for this HTTP connection while reading request, turn it on, this should never happen![%s] BUG: fd %d does not match fd %d in pollfd![%s] Connection idle time: %ld while in state: %d watching for event: %d,close![%s] Request body size: %d, received: %d.@z
}
}
}
}
}
}
}
}
T|


and under apache


lynx -mime_header http://123.123.123.123/~demosite/fdgksdjfgsdfh5554
HTTP/1.1 404 Not Found
Date: Wed, 16 May 2007 20:08:41 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

missing

[aww]

What is the possibility that litespeed is somehow closing the connection before the content is sent?

[mistwang]

updated 3.1.2 release should have this issue addressed.

[aww]

updated 3.1.2 release should have this issue addressed.

Ah, whew, so I am not going crazy?

I hope I helped find a bug. How many is that now? :rolleyes:

[mistwang]

Thanks for those bug reports.
The bug only exists in the Standard edition, we tested Enterprise edition in our lab. :)

[aww]

I installed that early 3.1.2 release a few hours ago and I am pleased to report that both the errordocument and the rewrite rules (as well as ~username) seem to be completely fixed and working exactly like apache now.

Many thanks for your help and the quick fix.

[aww]

Oh one last thing, and this is very trivial but still, if you want to mimic apache 100%

Even in 3.1.2
when there is no index.* in
http://ipaddress/~demosite/
it generates a litespeed standard 404 message
regardless if the ErrorDocument 404 is present

Now not only is the standard 404 message wrong when errordocument is present, you have to add Options -Indexes to get the errordocument 404 "missing

but I believe apache generates a 403 "forbidden" error, not a 404 error, when there is no index.* and Options -Indexes is present

The 403 vs 404 error might be critical in some log tracking software to trigger an alert for people going where they might not suppose to be trying to go.

[mistwang]

Please try the updated 3.1.2 release package, 403 should be returned now.