intermittent 500 error still

[jboy]

Hello,

I have an intermittent repeating 500 status error appearing in my access log for two particular files. According to the hosting company nothing appears in the error log for them.

(see my previous thread at [webmasterworld.com...]

The two files, from the outside, are css files, but they're actually php files.

The php seems to be working OK (that's not a 100% sure but things are pointing to the php being OK):
- the # of bytes transferred for the files, as reported by the access log, are correct when there's an error
- throughout the php code I've put database equivalents of echo()'s to see if things are Ok and even on error they are
Certainly the full php code is executing to the end seemingly correctly.

The two files are on a subdomain, their address from the outside:

subdomain.domain.com/css/file1.css
subdomain.domain.com/css/file2.css

and on the server their addresses are:

subdomain.domain.com/css/file1.css.php
subdomain.domain.com/css/file2.css.php

The full contents of
subdomain.domain.com/.htaccess
is

CookieTracking off

# stop auto index (which shows dir contents when there's no index.html/php file)
Options -Indexes

# caching -- start
Header unset ETag
FileETag None
Header unset Last-Modified
Header set Expires "Thu, 1 Jan 2030 00:00:00 GMT"
Header set Cache-Control "public, no-transform"
# caching -- end

RewriteEngine On
RewriteRule ^([^.]+)\.css$ /$1.css.php [NC,L]

Then at the top of the two erroring css/php files:
header('Content-type: text/css');

(I did have SetOutputFilter DEFLATE in a .htaccess, thought that might be the source of the problem, removed it, still getting errors -- no compression is involved in this problem now)

The headers the two files have look like this:

HTTP/1.1 200 OK
Date: Sun, 06 Feb 2011 11:25:17 GMT
Server: Apache/2.2.9 (Debian) mod_fcgid/2.3.5 Phusion_Passenger/2.2.15
Content-Location: file1.css.php
Vary: negotiate
TCN: choice
Expires: Thu, 1 Jan 2030 00:00:00 GMT
Cache-Control: public, no-transform
Connection: close
Transfer-Encoding: chunked
Content-Type: text/css

I doubt it's related to the error but why is reporting the actual file name ("file1.css.php")? And why:
Vary: negotiate
TCN: choice
?

I've tried unsetting those in a .htaccess in subdomain.domain.com/css/ but the unsets didn't remove those headers.

I've noticed browsers, esecially MSIE 6,7,8, are ingoring the caching directives for the two files which are erroring. On visits to further pages (file1.css is used on multiple pages) the browser keeps asking for it on each page visit, but I have a whole load of images in
subdomain.domain.com/img/
and those are being cached fine. Just for the record, the headers of one of the image files are:
HTTP/1.1 200 OK
Date: Sun, 06 Feb 2011 11:32:01 GMT
Server: Apache/2.2.9 (Debian) mod_fcgid/2.3.5 Phusion_Passenger/2.2.15
Accept-Ranges: bytes
Content-Length: 303
Expires: Thu, 1 Jan 2030 00:00:00 GMT
Cache-Control: public, no-transform
Connection: close
Content-Type: image/png

Not sure why I'm going on about headers, I doubt, although am not sure, they'd be a source of the problem. But there is something odd about the two files which are erroring as hinted at by their headers. Plus there's some oddness to those two files so far as .htaccess files go. I did have SetOutputFilter DEFLATE in
subdomain.domain.com/css/.htaccess
and that compression wasn't kicking in. I tried the compression in
subdomain.domain.com/.htaccess
and it did work (again, just to be clear, now there is no compression at all). It's just odd that something in one .htaccess doesn't work, but in another does. Not sure if that's because of the rewrite or not.

Apart from finding the error, which is the main point of this question, I'd also like to get rid of certain this:
Content-Location: file1.css.php
but also probably
Vary: negotiate
TCN: choice
(I guess there's some connection between those three headers). How to? Why are they there?

And, any suggestions what the 500 error might be?

Thanks.

[edited by: jdMorgan at 9:46 pm (utc) on Feb 7, 2011]
[edit reason] Linked to previous thread [/edit]

[jboy]

I've found something new out: The rewrite which was supposed to internally rewrite from
subdomain.domain.com/css/file1.css
to
subdomain.domain.com/css/file1.css.php
was never kicking in. I removed it and external accesses to subdomain.domain.com/css/file1.css still accessed subdomain.domain.com/css/file1.css.php...... MultiViews.

I put Options -MultiViews and now the rewrite is responsible for making subdomain.domain.com/css/file1.css accesses access subdomain.domain.com/css/file1.css.php. And, this has solved the header oddness (to me) I was talking about:
Content-Location: file1.css.php
Vary: negotiate
TCN: choice
have all gone now that MultiViews is off.

One thing this shows, I think, is that the 500 errors aren't/weren't coming from the rewrite rule. They're coming from somewhere else. Where, I have no idea.

[jboy]

Could the fact Multiviews was on, be the cause of 500 errors?

[jdMorgan]

Not to beat you on the head with this, but as I said before, you have little chance of fixing the problem if you do not have direct and timely access to your own server error logs. Most hosts (even the cheap name-based virtual server hosts) have provided for this fundamental service required for anything but a simple static-html hobby site.

As soon as you get into scripting or URL-rewriting, you need error log access. Offer to pay me $10,000 to fix your problem as-is, and I will refuse, because I could well end up losing money on the deal...

If you have turned off MultiViews and the 500 Errors yet persist, then no, the problem is not MultiViews.

Also, setting an expiry date in 2030 is unnecessary (and futile). I'd suggest that you use the Expires-time-after-access format for your .css and .css.php files (as well as .js files and images), such as

ExpiresActive On
<FilesMatch "\.css(\.php)?$">
ExpiresDefault A1296000
</FilesMatch>

or

ExpiresActive On
ExpiresByType text/css "access plus 1 month"

Both methods expire the .css resources after 30 days.

Putting an expires time of more than one month on anything is largely futile, as it's quite unlikely that your objects will remain in the users' caches even that long. Also, consider what happens if you need to correct or update your css -- As it stands today, if such a long cache time really would work, those users' browsers *would not* reload your new css, and would be rendering your site with broken styling until the year 2030...

Jim

[jboy]

> Most hosts (even the cheap name-based virtual server hosts) have provided for this fundamental service required for anything but a simple static-html hobby site.

Right, OK, I'll think about that, I wasn't aware of that. Thanks.

> If you have turned off MultiViews and the 500 Errors yet persist, then no, the problem is not MultiViews.

No they haven't persisted -- since MultiView off, no errors, but that's not saying much because not much time has gone by.

> Both methods expire the .css resources after 30 days.

Right excellent, I shall give that a go. That was going to be my next question, how to set that in a non hard coded date kind of way.

> lso, consider what happens if you need to correct or update your css -- As it stands today, if such a long cache time really would work, those users' browsers *would not* reload your new css, and would be rendering your site with broken styling until the year 2030...

I have considered that. I'm just using a name change file-1.css.php, when updated, file-2.css etc. But I take your point about it not staying cached in user's browsers long.

Thanks.