[Resolved] Content Encoding Error on .html but not .htm (same file, renamed)

[MikeDVB]

I have a customer who just has a very simple index.html in their public_html which is failing with this:
http://www.screen-shot.net/2010-06-06_1523.png

If I change the file name to .htm (from .html) it loads perfectly fine. If I leave it as .html and I go into the LiteSpeed Admin control panel and disable GZIP compression it loads fine.

I've never seen this issue before but admittedly not very many of our customers use .html files as most use .php.

I verified the issue with Enterprise v 4.0.13 and 4.0.14.

I did remove the .htaccess in the folder to make sure it wasn't causing an issue. I also made sure that GZIP Compression was disabled in their "Optimize Website" portion of their cPanel.

 

[MikeDVB]

Any ideas? I really need to get this resolved.

 

[mistwang]

Can you check the response header with firebug, I need to know what exact header causes the problem.
Have you tried different browser?

How about rename the file to "index2.html"? Try that file under a different domain?
I think it should be some thing special for that domain.

 

[MikeDVB]

Can you check the response header with firebug, I need to know what exact header causes the problem.
Have you tried different browser?

How about rename the file to "index2.html"? Try that file under a different domain?
I think it should be some thing special for that domain.

It's a newly created cPanel account (nothing special, nothing custom) no .htaccess file.

If you want to open a ticket with me in your support system I'm more than happy to give details and server access but I will check myself as well.

 

[MikeDVB]

Here's the headers for index.htm (which works fine)

Response Headersview source
Content-Encoding	gzip
Vary	Accept-Encoding
Date	Sun, 06 Jun 2010 23:03:23 GMT
Server	LiteSpeed
Accept-Ranges	bytes
Connection	close
Etag	"403-4c0c28ae-0"
Last-Modified	Sun, 06 Jun 2010 23:01:02 GMT
Content-Type	text/html
Content-Length	545
Request Headersview source
Host	[redacted]
User-Agent	Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB7.0 ( .NET CLR 3.5.30729)
Accept	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language	en-us,en;q=0.5
Accept-Encoding	gzip,deflate
Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive	115
Connection	keep-alive
Pragma	no-cache
Cache-Control	no-cache

When I do CTRL+F5 on index.html (reload without cache) it literally is blank and shows nothing in FireBug. When I press F5 (reload with cache) the headers look the same to me:

Response Headersview source
Date	Sun, 06 Jun 2010 23:04:28 GMT
Server	LiteSpeed
Accept-Ranges	bytes
Connection	Keep-Alive
Keep-Alive	timeout=5, max=100
Etag	"403-4bcca9a5-0"
Last-Modified	Mon, 19 Apr 2010 19:06:13 GMT
Content-Type	text/html
Content-Range	bytes 1-1026/1027
Content-Length	1026
Request Headersview source
Host	[redacted]
User-Agent	Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB7.0 ( .NET CLR 3.5.30729)
Accept	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language	en-us,en;q=0.5
Accept-Encoding	gzip,deflate
Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive	115
Connection	keep-alive
Range	bytes=1-
If-Range	"403-4bcca9a5-0"
Cache-Control	max-age=0

 

[mistwang]

When access the file with

curl -H "Accept-Encoding: gzip" .../index.html

The response body is blank.
Something is wrong, can you enable debug logging and check the debug log?
Or strace the child lshttpd process to find out what happened?
Please file a bug report to bug@litespeedtech... if you believe it is a bug.

 

[MikeDVB]

When access the file with

The response body is blank.
Something is wrong, can you enable debug logging and check the debug log?
Or strace the child lshttpd process to find out what happened?
Please file a bug report to bug@litespeedtech... if you believe it is a bug.

I'd rather just give you access to the server and have you do whatever testing you want as I do believe it's a bug (although maybe an obscure one).

Just keep in mind it is a production server so please do your best to avoid making any changes that could cause downtime.

Just respond to my PM and tell me what details you need.

 

[MikeDVB]

I sent over the server details to bug@litespeedtech...

 

[mistwang]

The problem is the gzip cache for that file is blank, maybe the timestamp on the file is older than the gzip cache, so the cache was not updated. After touching the file, the gzip cache updated and page served properly.

 

[MikeDVB]

Very interesting - is there a particular reason this happened and a setting to perhaps change to prevent it from happening again or is it just a one-off type of issue.

Touching a file is easy and is a quick resolution so it's not a major deal as long as it doesn't happen often (which this is the first in over 8 months).