Help! Really strange behavior from Apache

N

neph

Registered
I've got an Xserve serving some web sites, and a particular directory in one of the sites is acting really strangely lately.

Basically, it's throwing 403 "Forbidden" errors. But it is really inconsistent about it. Sometimes, the HTML page itself will come back 403, presenting the error document to me. Sometimes, the HTML page comes in fine, but the style sheet comes back 403, so the page is unstyled. Other times, both come back fine. Sometimes, just the print style sheet is forbidden, so it looks fine unless you try to print it.

Watching the 'Activity' window in Safari while repeatedly reloading a file in the directory, I'll see different documents referenced by the web page come back as forbidden, different ones with each reload. As far as I can tell, it's random which pages come back fine and which ones come back 403.

More curiously, if I restart the web service, the problem goes away for a few hours and then returns. When I finally went to bed defeated last night, I checked it in the morning, and it came back solid 403 until I restarted the web service again, so it apparently gets worse over time.

The usual culprits of 403 errors aren't to blame here - I have triple-checked the permissions. Nothing is changing the permissions on those files, especially moment-to-moment like that, so it's obviously something else.

I have tried uploading a new version of the directory from my home computer, but that did not fix it. I've also repaired permissions on the server. Both things seemed to fix it at first, but then a few hours later, the problem would resurface.

The weird thing about it is that this is just another non-special subdirectory. There are sibling subdirectories to this one that work fine. There are no special .htaccess files or anything between them.

All I can think of is either disk corruption, or maybe something like multiple processes trying to access those .html or .css files at the same time, locking each other out. Or maybe the server doesn't have enough connections free, and is sending back 403's for some reason.

Any ideas? I'm at my wit's end here.
 
Make sure your directory has the correct permissions set to allow the web server read it.
Assuming you have no special permissions set, you could try the following in the Terminal:

Code: 
sudo chmod -R 755 /your-directory-here

By default in Mac OS X, the www root directory is /Library/WebServer/Documents/, so:

Code: 
sudo chmod -R 755 /Library/WebServer/Documents
 
Thanks for the reply.

Yeah, I've set all the permissions in the directory so that they're readable by all, like you mentioned.

The webserver can read the files - indeed, it often does. The problem is that Apache just randomly decides to forbid or allow access to them, even though the permissions are set, from one moment to the next.

Any other suggestions?
 
neph said:
Thanks for the reply.

Yeah, I've set all the permissions in the directory so that they're readable by all, like you mentioned.

The webserver can read the files - indeed, it often does. The problem is that Apache just randomly decides to forbid or allow access to them, even though the permissions are set, from one moment to the next.

Any other suggestions?
Click to expand...

That's strange. Are other users allowed to override apache settings in .htaccess files? Check if there are any in the troubled directories.
 
Thanks for the link. That's more info than what I've typically found Googling.

Going through the suggestions on that page:

* It's obviously not a 'No directory browsing' problem, since it is forbidding specific files, like the CSS file.

* The directory is not secured - all casual traffic is allowed.

* I have not recently changed ISP's or anything. Other files in the directory show up fine, so it's not a 'site moved' thing.

* The behavior has been verified independently by third parties.

The only thing that sounds promising from that page is this: "...it is possible that your Web server (or surrounding systems) have been configured to disallow certain patterns of HTTP traffic."

I work at a university, and perhaps they have some strictures in place that prevent different kinds of traffic. Maybe if it detects too much of a given type of traffic that this problem directory somehow triggers, then it throttles it back, returning 403's.

But in that case, wouldn't the 403 come from something other than my server? Or could there be some of these strictures in place by default on Mac OS X Server? I haven't implemented something like that myself, and looking in the Apache config files, the only such thing I see is the block against downloading things like .htaccess files (but then, I am not an Apache configuration guru, so I could easily be missing something).
 
ksv said:
That's strange. Are other users allowed to override apache settings in .htaccess files? Check if there are any in the troubled directories.
Click to expand...

Well, I have AllowOverride on, but there is not an .htaccess file in that directory. And it's not inheriting any weirdness from the parent directory, either, because sibling directories, also without .htaccess files, aren't exhibiting this behavior.
 
Not that I can see, and I have logging at level 'information' turned on. The access log has entries that note that the request was denied, and they typically look like this:

128.123.xxx.xxx - - [14/Feb/2005:12:18:37 -0700] "GET /faulty_directory/somefile.html HTTP/1.1" 403 2931

...where 'faulty_directory' is the offending directory.
 
In case someone else has this same problem, and comes here looking for a solution, I managed to fix the problem with the help of an Apple help desk person.

The problem was fixed by issuing a 'changeip' command in the terminal window. Even though I hadn't changed IP's, I *had* turned off a hostname and added another, so doing a changeip from the old hostname to the new hostname fixed it.

Why it was causing such strange behavior in such a localized area is still a mystery, but the important thing is that it is working.
 
You must log in or register to reply here.
Back
Top