I think we will need to see some of your .htaccess to give definitive answers.

I suspect that the CSS failed because the link to it is not absolute.

...

It's a new site about to launch. Still testing and putting up the miscellany. Only 150 pages or so total, and only a couple of dozen that are critical truth be told, so not much at all in the .htaccess yet. Haven't seen the need as yet.

ErrorDocument 404 http://www.example.com/404.html
ErrorDocument 403 http://www.example.com/403.html
ErrorDocument 401 /auth_failed.html
AddType application/x-httpd-php .html
Options -Indexes
<Files .htaccess>
order allow,deny
deny from all
</Files>

You were right about the CSS and the relative link. The 403 and 404 pass with that relative link sail through; they render and validate. If I call for it as an absolute path with the 401 it validates fine, and seems to process fine. (Admit, just a quick test thus far in IE only using the absolute path to the CSS and with the CSS removed from the head of the page.)

Why the CSS relative path failure for rendering and validation with only the 401 (named as auth_failed.html)?

Further suggestions, input, and 'best practice' advice?

The ErrorDocument calls in your .htaccess should be relative.

All included files in the documents themselves should be absolute.

...

All included files in the documents themselves should be absolute.

An absolute rule, or a preference? I've always been a relative path guy within my site structures. Have considered going absolute at times with some sites (includes, navigation, the whole shebang) to avoid potential nightmare of a major change in structure that would wreak havoc with a site - but have always figured that in that event I'll be doing some sort of major revamp anyway so it won't matter all that much. Of course, my sites run up to a few hundred pages max, not thousands like a lot of folks here.

<edit - spellin'>

[edited by: D_Blackwell at 3:13 am (utc) on June 22, 2008]

For custom error documents all external links should be absolute.

If the file that produces the error is in a subdirectory then relative paths will not work.

Likewise, the path in .htaccess must be relative to produce the correct status code.

Such is my understanding (but there are smarter people than me in this forum)

...

Let's put it more strongly:

All ErrorDocument URLs MUST be relative (a local URL-path) -- otherwise a 302-Found status response will be returned regardless of the error condition being reported, as documented in the ErrorDocument documentation.

All links to pages and included object links within errordocuments MUST be absolute, since the errordocument "replaces" the the originally-requested resource, and "adopts" its URL (check the address bar when viewing an errordocument in response to an error). Otherwise, the client will resolve relative links within an errordocument based on the originally-requested URL (e.g. the address in the browser's address bar), and in many cases will therefore resolve to incorrect locations.

Jim

Just adding a 'simple' 401 has caused all kinds of problems that I didn't know I had. Until now I seem to have 'gotten away' with paths that worked in the other files, which maybe shouldn't have. Now I've blown them all up - especially the includes. And after putting them back the way the were, everything worked except the includes.?

Ok.
1)

ErrorDocument 404 /404.html
ErrorDocument 403 /403.html
ErrorDocument 401 /auth_failed.html
AddType application/x-httpd-php .html
Options -Indexes
<Files .htaccess>
order allow,deny
deny from all
</Files>

2) Changing the include paths from relative to absolute blew them up - in the 404, 403, and 401. Backtracking to where I started with the relative paths (which always 'worked before' didn't help.?

So:
<?php
include ("http://www.example.com/includes/logo-header.inc");
?>
Didn't work; though it worked for the CSS file, and the images. Why not?

Did some more research (the error message helped):
<?php
include ("/usr/www/users/blackwel/domain-folder/includes/logo-header.inc");
?>
Does work and fixed the includes in all three files. Not sure what I've learned yet; still working on that:))

Why did the first absolute attempt not work and the second was successful? It was good enough for the other absolute paths. (I did try ("/includes/logo-header.inc"); - which did not work,but assume that that is not the 'real' absolute path in this case.)

Why have my relative includes always worked with the 404 and 403s (for years) and are still working on other domains, but now apparently 'blown up' on this one? (Looks like I've got some repair work to do on the other domains.?)

Why does auth_failed.html seem to be 'required', and 401.html does not work? Is this a unique requirement or standard?

Flush your browser cache after changing any code on your server.
Make sure that 401, 403, and 500 error pages are non0cacheable.
If your server-relative or canonical object references do not work, that means that the path is wrong.
PHP includes should be local filepaths, not URLs, unless you are wanting to access resources in another domain.

Jim

You can also avoid relying on the system path remaining the same (and use a more 'url' like structure by using the

$_SERVER['DOCUMENT_ROOT']

variable, i.e.

include $_SERVER['DOCUMENT_ROOT'] . '/includes/logo-header.inc';

Why have my relative includes always worked with the 404 and 403s (for years)

Because they were redirecting due to the absolute URLs ;)

One thing that may help clarify is that object references such as <img src="xyx.gif"> on HTML pages are "client-side includes" -- That is, the client browser uses HTTP to "GET" those objects from your server using a URL.

When an include is server-side, as it is for PHP or PERL or SSI, then the script is including the referenced object from the local filesystem on the server, and so should use a filepath, not an HTTP URL.

And a further clarification --maybe an eye-opener, or completely obvious-- but the fundamental purpose of a server is to translate "Universal" Resource Locators (ULRs) or, if you prefer, Universal Resource Indentifers (URIs) to server filepaths, regardless of the OS or filesystem in use on that server.

This is what URLs/URIs are for -- so that Web resources can be found without having to know what OS and filesystem they are hosted on. Imagine if the URL format had to change depending on whether the site was hosted on *nix, Solaris, Windows, etc... "No you dummy, it's not http://www.example.com/forum/post92.html, it's on Windows so everybody knows you have to use http://www.example.com/forum\post92.htm !"

Jim

The clarification as to what is an externally facing URL and what is a file-path on a hard-drive, and when to use one or the other, is crucial to the understanding of this stuff.

Likewise, when to use absolute references, and when to use relative, is also very important.

It appears that my incorrect:

ErrorDocument 403 http://www.example.com403.html

allowed my incorrect relative paths within those documents to 'work' - including the includes.
................

By incidentally calling for the ErrorDocument correctly:

ErrorDocument 401 /401.html

it seems that I blew up the ability to get away with at least some of the other errors.
................

I have updated, correctly I believe, the 404, 403, and added a 401 to another domain on another server.

Ran into the same issue on the includes, i.e., the absolute URL file path would not work. In this case also, the error message provided the obvious clue to the fix.

<?php
include ("/home/.funnygirl/d_blackwell/example.com/dbwd/logo.inc")
?>

and all is well again - and correct - and I getting closer to learning what it is that I have learned:))
................

Went back to the other domain on the other server and did some file renaming as a test. Turns out that it really does not care what I name the 401 file so long as my paths and references are correct.
................

You can also avoid relying on the system path remaining the same (and use a more 'url' like structure by using the $_SERVER['DOCUMENT_ROOT'] variable, i.e.

include $_SERVER['DOCUMENT_ROOT'] . '/includes/logo-header.inc';

Beaten myself up enough for one day. May add 500s and try this method for them; if only temporarily for the experience. Probably ought to implement them all the same way when I'm done:))
................

Googling some research on this question brought up quite a lot of inconsistency in what is 'correct'. That didn't help at all.
................

Am I closer to 'having it'? Thanks to all.