You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by wr...@locus.apache.org on 2000/11/03 01:55:29 UTC
cvs commit: apache-1.3/src/modules/standard mod_autoindex.c
wrowe 00/11/02 16:55:28
Modified: . STATUS
src CHANGES
src/modules/standard mod_autoindex.c
Log:
Resolve mod_autoindex caching problems by returning the mtime as the
Last-Modified tag, and assigning the ETag. Already applied to the
Apache 2.0 tree.
Revision Changes Path
1.856 +1 -7 apache-1.3/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/apache-1.3/STATUS,v
retrieving revision 1.855
retrieving revision 1.856
diff -u -r1.855 -r1.856
--- STATUS 2000/11/03 00:44:01 1.855
+++ STATUS 2000/11/03 00:55:25 1.856
@@ -1,5 +1,5 @@
1.3 STATUS:
- Last modified at [$Date: 2000/11/03 00:44:01 $]
+ Last modified at [$Date: 2000/11/03 00:55:25 $]
Release:
@@ -41,12 +41,6 @@
and over again once they return a 'fatal' error (e.g. volume
full, bad args, etc.)
Status: Victor Orlikowski is working up a patch
-
- * mod_autoindex results return no timestamp, so they are cached
- past their legitimate lifetime. Patch to add ETag and
- Last Modified based on directory mtime posted to new-httpd
- Message ID <00...@covalentwrowe1>
- Status:
* long pathnames with many components and no AllowOverride None
Workaround is to define <Directory /> with AllowOverride None,
1.1593 +4 -0 apache-1.3/src/CHANGES
Index: CHANGES
===================================================================
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1592
retrieving revision 1.1593
diff -u -r1.1592 -r1.1593
--- CHANGES 2000/11/03 00:44:00 1.1592
+++ CHANGES 2000/11/03 00:55:27 1.1593
@@ -1,5 +1,9 @@
Changes with Apache 1.3.15
+ *) Eliminate caching problems of mod_autoindex results, so the last
+ modified date of the directory is returned as the Last-Modified
+ tag, and an appropriate ETag is sent. [William Rowe]
+
*) Corrected file path arguments from server conf directives to
their canonical form (excluding OS2 - which uses alternate
logic.) Resolves a long list of PRs reporting that Win32 paths
1.115 +4 -1 apache-1.3/src/modules/standard/mod_autoindex.c
Index: mod_autoindex.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_autoindex.c,v
retrieving revision 1.114
retrieving revision 1.115
diff -u -r1.114 -r1.115
--- mod_autoindex.c 2000/02/02 20:44:01 1.114
+++ mod_autoindex.c 2000/11/03 00:55:28 1.115
@@ -1615,7 +1615,10 @@
}
r->content_type = "text/html";
-
+ ap_update_mtime(r, r->finfo.st_mtime);
+ ap_set_last_modified(r);
+ ap_set_etag(r);
+
ap_send_http_header(r);
if (r->header_only) {
RE: cvs commit: apache-1.3/src/modules/standard mod_autoindex.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Friday, November 03, 2000 10:43 AM
>
> On FAT & HPFS, the directory's mtime == creation time, it
> never changes.
I was about to use that for the test, but there is something
odd in Win32... mtime ~= ctime, but the resolution is different.
I haven't tested with stat() (I'm playing around with FindFirstFile()
and GetFileAttributesEx() right at the moment) so I will do that
next, but if we are sure of this behavior with stat, we can most
certainly drop Modified-Time in those cases, saving build time
conditionals and extra volume type testing.
I'd argue that although the file timestamp changes for JFS
entries aught to be reported, I'm more concerned with the case that
new files are added and deleted, so the links to those files should
be changing. It would be good if Last-Modified tag was revised for
these cases, but it's not the end of the world, IMHO. Your thoughts?
Also, do you have good dev/inode tags of meaningful value from the
stat() call? Or shall we drop ETag as well, and on what condition?
Finally, what to do when ctime==mtime, or we otherwise know this
patch just won't work. What tags aught we send to be reasonably
sure the user isn't looking at horribly stale data? The idea of
prereading the whole tree and stating all it's members makes me
somewhat sick to my stomache :-(
Bill
RE: cvs commit: apache-1.3/src/modules/standard mod_autoindex.c
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Fri, 3 Nov 2000 09:25:16 -0600, William A. Rowe, Jr. wrote:
>> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
>> Sent: Friday, November 03, 2000 10:12 AM
>>
>> On 3 Nov 2000 00:55:29 -0000, wrowe@locus.apache.org wrote:
>>
>> > Log:
>> > Resolve mod_autoindex caching problems by returning the mtime as the
>> > Last-Modified tag, and assigning the ETag. Already applied to the
>> > Apache 2.0 tree.
>
>> I believe this fix relies on a file system behaviour that is not universal,
>> that is the mtime of a directory is updated whenever a file in it is
>> modified. Of the file systems I have on my machine here (FAT, HPFS, JFS)
>> only JFS does this. I'll probably have to special case this on OS/2 as HPFS
>> is the most commonly used file system on it. JFS is only available on the
>> latest server version of OS/2, v4.5 aka "Warp Server for e-business".
>>
>
>I expected, that's why I asked for comments earlier.
>
>Every unix (true readdir platforms) will support this, correct?
>NTFS on NT does. What about NetWare?
>
>FAT will not. On 9x it returns ctime (somewhat of a problem, but
>no worse than the current unstamped flavor for most proxies and
>browser caches.) On NT the FAT directory returns now(), which isn't
>necessarily a bad idea since we know it's volitale, but there could
>be a better exception for it. I can consistify them within the
>os_stat() function of the Win32 port, to either behavior, or return
>simply mtime of 0 and tag the header as volatile rather than stamped.
>
>But what do you observe from OS2 on those older filesystems?
>Would a test for (!mtime) help?
After a bit more testing I've concluded that none of the file systems in
general use on OS/2 update the directory mtime for every change to that
directory that affects the output of the autoindex. Even JFS only updates
the mtime if a file is created or deleted, touching an existing file
doesn't.
On FAT & HPFS, the directory's mtime == creation time, it never changes.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
RE: cvs commit: apache-1.3/src/modules/standard mod_autoindex.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Friday, November 03, 2000 10:12 AM
>
> On 3 Nov 2000 00:55:29 -0000, wrowe@locus.apache.org wrote:
>
> > Log:
> > Resolve mod_autoindex caching problems by returning the mtime as the
> > Last-Modified tag, and assigning the ETag. Already applied to the
> > Apache 2.0 tree.
> I believe this fix relies on a file system behaviour that is not universal,
> that is the mtime of a directory is updated whenever a file in it is
> modified. Of the file systems I have on my machine here (FAT, HPFS, JFS)
> only JFS does this. I'll probably have to special case this on OS/2 as HPFS
> is the most commonly used file system on it. JFS is only available on the
> latest server version of OS/2, v4.5 aka "Warp Server for e-business".
>
I expected, that's why I asked for comments earlier.
Every unix (true readdir platforms) will support this, correct?
NTFS on NT does. What about NetWare?
FAT will not. On 9x it returns ctime (somewhat of a problem, but
no worse than the current unstamped flavor for most proxies and
browser caches.) On NT the FAT directory returns now(), which isn't
necessarily a bad idea since we know it's volitale, but there could
be a better exception for it. I can consistify them within the
os_stat() function of the Win32 port, to either behavior, or return
simply mtime of 0 and tag the header as volatile rather than stamped.
But what do you observe from OS2 on those older filesystems?
Would a test for (!mtime) help?
Re: cvs commit: apache-1.3/src/modules/standard mod_autoindex.c
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On 3 Nov 2000 00:55:29 -0000, wrowe@locus.apache.org wrote:
> Log:
> Resolve mod_autoindex caching problems by returning the mtime as the
> Last-Modified tag, and assigning the ETag. Already applied to the
> Apache 2.0 tree.
[...]
> --- mod_autoindex.c 2000/02/02 20:44:01 1.114
> +++ mod_autoindex.c 2000/11/03 00:55:28 1.115
> @@ -1615,7 +1615,10 @@
> }
>
> r->content_type = "text/html";
> -
> + ap_update_mtime(r, r->finfo.st_mtime);
> + ap_set_last_modified(r);
> + ap_set_etag(r);
I believe this fix relies on a file system behaviour that is not universal,
that is the mtime of a directory is updated whenever a file in it is
modified. Of the file systems I have on my machine here (FAT, HPFS, JFS)
only JFS does this. I'll probably have to special case this on OS/2 as HPFS
is the most commonly used file system on it. JFS is only available on the
latest server version of OS/2, v4.5 aka "Warp Server for e-business".
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------