error document returning 200

[chewy]

Hi - this is definitely happening and I can't seem to figure it out.

When I force a 404 with this one case I am working on, I am getting a 200 code.

This is a problem and I have edited the htaccess file to try to correct the problem.

When I use the following line,

ErrorDocument 404 /p/404.html (and, yes, there is an actual page called 404.html there)

THIS is definitely returning a 200.

When the full path is in place, it returns a 302 - as stated previously this is how it is supposed to work, right?

(you know ErrorDocument 404 https//:www.xxxxx.com/p/404.html)

Of course, I want a 404 to actually create a 404 like it is supposed to.

Oddly, I can't seem to get this checking tool to return any 404's (say, for instance, on this site)

SOOO, have these tools maybe stopped working somehow?

This is going to be interesting.

I hope I've just got some odd simple keystroke error here...

thanks!

-C

[not2easy]

You are seeing the 200 response for the 404.html, correct? Is the custom 404.html shown? That would happen if it is "found" and served. Depending on what you are using to check the server response you may or may not see the 404 response in the tool, but look at the access logs and they should be showing the file requested as returning a 404 if it does not exist/is not found. I don't know why it should return a 302 (Temporarily Moved) response.

[phranque]

THIS is definitely returning a 200.

When the full path is in place, it returns a 302

have you tried using a browser tool such as Chrome's Developer Tools or the Live HTTP Headers addon for Firefox?
as not2easy suggests i would also see what clues the server access and error logs provide.

regarding the 302 - see this:
https://httpd.apache.org/docs/current/mod/core.html#errordocument

Note that when you specify an ErrorDocument that points to a remote URL (ie. anything with a method such as http in front of it), Apache HTTP Server will send a redirect to the client to tell it where to find the document, even if the document ends up being on the same server. This has several implications, the most important being that the client will not receive the original error status code, but instead will receive a redirect status code. This in turn can confuse web robots and other clients which try to determine if a URL is valid using the status code. In addition, if you use a remote URL in an ErrorDocument 401, the client will not know to prompt the user for a password since it will not receive the 401 status code. Therefore, if you use an ErrorDocument 401 (or 404) directive, then it must refer to a local document.

[chewy]

Yes, I understand the 302 and why it is doing what it is doing. Thank you Phranque.

And I am absolutely positive that this is throwing a 200 error. There is no doubt in my mind.

HTTP SPY just confirms what I've been seeing all along.

This is a clear flaw somewhere outside of my htaccess skills.

Is it possible that an Apache RedHat type server could actually not be configured correctly and it is somehow ignoring the Error Document command?

Or is it more likely that some other part of the htaccess file is conflicting with the Error Document statement?

I have removed all but "rewrite engine on" and used just the error document directive as a test and it does return 404 but doesn't redirect per the "/" only type path.

Pls what might I be overlooking?

[not2easy]

Have you tried moving the 404.html file to the same directory as the .htaccess file and changing the .htaccess to:

ErrorDocument 404 /404.html

so that the named error document is a local file?

[chewy]

not2easy nailed it!

and we have yet another SCORE for WebmasterWorld!

Yes that has solved the problem.

No idea why the thing won't work on anything but the root, but that is one more example of awesome...

High Fives all around.

And happy new year wherever you are, OK?

Thanks!


PS - one more reason why WebmasterWorld continues to be well worth the price!

[lucy24]

It's nice that it works, but I'd still like to be sure why it works.

No idea why the thing won't work on anything but the root, but that is one more example of awesome...

In not2easy's post, part of her advice was to put the error document in the same directory as the htaccess. This implies that the htaccess might be located somewhere other than the root. The catch is that it shouldn't make any difference. If you have an htaccess in a subdirectory, the leading / is still interpreted as site root.

For example (this is something I've actually got in place, so I'll use the real directory name):
Directory /ebooks/ uses a different 404/410 document from the rest of the site. Since you can't have a <Directory> section in htaccess, the directory has its own supplementary htaccess file consisting solely of the two lines

ErrorDocument 404 /ebooks/gone.html
ErrorDocument 410 /ebooks/gone.html

The root is still the root. (If I edit it to /gone.html alone, I get one of those recursive error messages that say "I can't find the document, and I also can't find the 404 document.”)

What will not work is if you try to put an ErrorDocument at a higher level, such as a userspace. (Some directives--notably access control--work fine in htaccess at this level, but some don't. It takes some trial and error.)

Disclaimer: It may work differently if you're in a primary/addon directory structure. In that case, I would expect it to work only in the primary, or only in the addon, but not both.

[phranque]

No idea why the thing won't work on anything but the root,

I'm still assuming the answer is in the error log file.

[not2easy]

In the OP chewy tells us that htaccess had this line for the 404:

ErrorDocument 404 /p/404.html

Assuming that the htaccess file being discussed was at the root directory, then the 404 page was not in the root. I assumed that the htaccess was in the root because usually that is where it would be and also because if it were in the /p/ directory then it would have worked as expected. ;)

See phranque's quote above.

[lucy24]

Assuming that the htaccess file being discussed was at the root directory, then the 404 page was not in the root.

But that's the part that definitely shouldn't make any difference. I don't know about most people, but I tend to collect my error documents in a directory called something imaginative like /boilerplate/ so it's by definition not in the directory containing htaccess.

Come back, chewy! I'd still like to know where the original htaccess was, and where you moved it to :)

[chewy]

I'm here -

The htaccess file was in the root and the simple fact is the 404 page seems to only work when placed in the root.

That was an easy fix. I hope. I keep finding other issues but they seem to be minor. See my next post...

Part of the situation here is the htaccess file has to live in the root as I assume any broken links could be coming in to ANY directory.

Well, that and I've never put htaccess in other directories because, well, I just never had to - but I do know that WordPress and other CMS's do put them all over the place. That's why I prefer WP. but in this case this is a new CMS that I don't particularly like but I'm able to engineer various workarounds - so far.

[lucy24]

Part of the situation here is the htaccess file has to live in the root, as ...

The root is definitely where the htaccess belongs. Sometimes you need to throw in supplementary htaccess files if selected directories have, for example, different auto-indexing rules. (The kind of thing that in a config file you'd put in additional <Directory> sections.) But those would just be a few lines; not a whole htaccess from scratch. And sometimes, if you've got multiple sites sharing a userspace, you can put access control in a higher-level htaccess so you only have to make one set of rules.

That being the case, it's mystifying that your server insists on error documents also being in the root. Possibly there's something wonky about the server's aliasing rules, which would be out of your power to correct :(