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 </Directory> 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).
This is probably a manifestation of PR#41829. Can you apply the (one-line) patch and see if it goes away?
The problem persists after applying the patch mentioned.
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.
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?
Created attachment 20575 [details] Patch against trunk
Ruediger, I don't think that patch completely eliminates the bug. Consider the following: <directory /a> FileETag None </directory> <directory /a/b> FileETag +mtime </directory> <directory /a/b/c> FileETag -mtime </directory> 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.
I put some thoughts about refactoring options parsing at: http://segundo.ricilake.net/options.txt 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.
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.
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.