nested ErrorDocuments not working

[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]

Originally Posted by mistwang

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?

[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.