ETag not for Folders.

Missing In Action...

[g1smd]

After reading the article at [webmasterworld.com...] I have been looking at the eTag setup on a site.

The tag is added for HTML, CSS, image, and JS files, but does not get added for folder URLs (like www.example.com/folder/ for example).

I had a quick look at [webmasterworld.com...] and a few other threads, but can't see a simple way to add the tag for those HTML pages that are really index files, but which are called using a folder-based URL.

I had never previously checked this setup before. I see that setting as being a flaw which I now want to put right.

[jdMorgan]

> pages that are really index files

What type of files are they? ... The Apache directives such as <Files> and FileETag do apply to files, not URLs, and so should be usable for index pages.

Jim

[g1smd]

They are index.php or index.html files, but they are linked to only as www.domain.com/folder/ internally.

[jdMorgan]

It doesn't matter what URL is used -- What matters is what file the URLs resolve to. The eTag directives are filename-based, as stated above -- or they're documented as filename-based, just as <Files> and <FilesMatch> are...

Jim

[g1smd]

I went back and checked again. I can't believe that I missed the "this applies to files" mantra that applies in rewrites as also applying here. I find the Apache documentation a tad indigestible.

It looks like .css, .jpg, .gif, .js URLs/files do return the eTag, but .php URLs/files on this site do not. The one true .html URL present on the site does, as does the site root at "/" which is also a .html file. So, it is a .php problem, not a folder problem. My mistake.

In any case, once the site does go live all of the URLs will be .html URLs, whether or not any PHP scripts reside inside the files. The site is currently being developed on a "test" subdomain, and the whole lot is disallowed in robots.txt too.

[jdMorgan]

The most likely reason you're not getting eTags is that Apache "knows" -at some level- that php files are dynamic, and therefore, they cannot be cached by default, because the assumption is that they change every time they're requested (else why would they be dynamically-generated?).

You might want to look around here and on the Web for ways to cache the php page output as non-php files on the server, rewrite the .php URLs to those server-cached non-php files, and the server will then happily stick an eTag on them.

And yes, URLs are not files. :)

Jim

[g1smd]

You don't need to tell me that URLs are not files. LOL.

Although the files have PHP scripts in them, all the PHP stuff does is to include headers, footers, navigation, and so on, and dynamically build the breadcrumb trails to the content. Oh, and it passes the document title, meta description, and date of last edit, on to other bits of the code where the information is actually used.

The site is essentially "static". Content pages are edited and uploaded, and the navigation "include" files are edited and uploaded with typically one or two changes every month.

There is little need for a CMS, or database at present.

The live site will use AddType to let the .html files/URLs be PHP scripted content. That should essentially fix the eTag issue too.

[encyclo]

1. ETag not eTag ;) Pedantic, yes, but if you end up using

header

in PHP to set the Etag then case counts.

2. Is this of any help?
[bugs.php.net...]
(see comments about running the PHP engine as CGI not an Apache module)

[g1smd]

Well, I knew I had seen it with a capital T many times, so when various sites show it as Etag, I know they were wrong, and simply assumed what was correct would be eTag. Thanks for the heads up. I always appreciate using the correct terminology for things. Hmm. I got it right (but only) in the title.

*** Is this of any help? ***

It might be... but not at 2.40 a.m. ;-)

Give me a day or two to take a look.