Bug 42027 - FileETag directive appears to be ignored
Summary: FileETag directive appears to be ignored
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.2.4
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2007-04-02 20:26 UTC by Bug Reporter
Modified: 2018-11-07 21:08 UTC (History)
0 users

Patch against trunk (1.61 KB, patch)
2007-07-31 13:00 UTC, Ruediger Pluem
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bug Reporter 2007-04-02 20:26:33 UTC
I am trying to control ETag generation. According to the docs, the FileETag
directive should work inside a .htaccess with the FileInfo override.

Here is my directory block in httpd.conf:

<Directory "/home/me/public_html">
        AllowOverride All
        Options All

        order deny,allow
        allow from all

My .htaccess in /home/me/public_html/i/.htaccess contains the following:
FileETag None

Yet, a GET request for foo.com/i/bar.jpg still returns an ETag seemingly
comprised of all the available information (INode, MTime, Size).

I tried also placing the FileETag None in the <Directory> block, thinking
perhaps the documentation was incorrect and I had the same result. httpd was
restarted in between all changes. No errors were logged in the error_log
(loglevel warn).
Comment 1 Nick Kew 2007-04-03 02:33:24 UTC
This is probably a manifestation of PR#41829.  Can you apply the (one-line)
patch and see if it goes away?
Comment 2 Bug Reporter 2007-04-03 13:00:43 UTC
The problem persists after applying the patch mentioned.
Comment 3 Rici Lake 2007-07-31 11:32:43 UTC
I believe this is a copy&paste error at line 392 of server/core.c (in trunk,
line 420 in 2.2.4):
391 : conf->etag_remove =
392 :   	(conf->opts_remove & (~ new->etag_add)) | new->etag_remove;

line 392 should read:

392 :   	(conf->etag_remove & (~ new->etag_add)) | new->etag_remove;

In addition, I believe there is an error in the parsing of FileETag, at:

1599 :  if ((cfg->etag_bits & ETAG_NONE) != ETAG_NONE) {
1600 :  	cfg->etag_bits &= (~ ETAG_NONE);

That's a no-op; I think line 1599 should read:

1599 :  if (cfg->etag_bits != ETAG_NONE) {

However, the correction of cfg->etag_bits at in the merge (line 402/403) should
mask the effects of this error in the majority of cases.
Comment 4 Ruediger Pluem 2007-07-31 12:59:29 UTC
While I was not able to reproduce the original issue I agree that the FileETag
configuration contains a bug. Parts of it are fixed by Rici's proposal, but
there is also another issue. Could you please give the attached patch (against
trunk, but works also against 2.2.x) a try and report back?
Comment 5 Ruediger Pluem 2007-07-31 13:00:22 UTC
Created attachment 20575 [details]
Patch against trunk
Comment 6 Rici Lake 2007-07-31 16:27:54 UTC

I don't think that patch completely eliminates the bug.

Consider the following:

<directory /a>
FileETag None
<directory /a/b>
FileETag +mtime
<directory /a/b/c>
FileETag -mtime

You might expect files in /a/b/c to have no etags. However, with a stock 2.2.4,
they end up with mtime+inode+size, and with the patch they end up with inode+size.

Comment 7 Rici Lake 2007-07-31 21:14:32 UTC
I put some thoughts about refactoring options parsing at:


Maybe they're useful. I was trying to not be too clever, be explicit
in invariants, and get the semantics reasonable (while allowing
AP_INIT_ITERATE argument parsing). The semantics are not quite
the same as current httpd: for one thing, it throws errors on certain
constructions (Options +Foo -Bar Glitch) and for another thing it
allows you to split up absolute options over various Options directives
in the same block, so that:

  Options Foo
  Options Bar

(in one block) is the same as:

  Options Foo Bar

I'm not sure whether those are plausible changes, but it seems like it would
be useful to have a single library which did httpd-options style handling in
a consistent way.

By the way, the current FileETags error can be reproduced if you have
  Options -Indexes
in a block which is merged with a block containing:
  FileETag None
(because OPT_INDEXES is the same value as ETAG_NONE). So, for example, putting
the 'FileETag None' directive in a vhost, and the 'Options -Indexes' directive
in a <Directory> section will probably trigger the error when the directory
and the vhost are merged.
Comment 8 Ruediger Pluem 2007-08-05 05:56:57 UTC
I fixed at least the copy and paste error (opts_remove vs etag_remove) in trunk
as r562860 (http://svn.apache.org/viewcvs.cgi?rev=562860&view=rev) and proposed
it for backport to 2.2.x r562862
(http://svn.apache.org/viewcvs.cgi?rev=562862&view=rev). Solving the other
issues requires for time and thoughts.
Comment 9 William A. Rowe Jr. 2018-11-07 21:08:42 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.