httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <r...@imdb.com>
Subject Re: [PATCH] some cleanups and bug fixes
Date Sun, 03 Aug 1997 11:47:46 GMT
On Sat, 2 Aug 1997, Roy T. Fielding wrote:

> >Index: http_protocol.c
> >===================================================================
> >RCS file: /export/home/cvs/apache/src/http_protocol.c,v
> >retrieving revision 1.146
> >diff -u -r1.146 http_protocol.c
> >--- http_protocol.c	1997/07/30 18:41:52	1.146
> >+++ http_protocol.c	1997/07/31 09:31:09
> >@@ -350,10 +350,9 @@
> > {
> >     char *etag, weak_etag[MAX_STRING_LEN];
> >     char *if_match, *if_modified_since, *if_unmodified, *if_nonematch;
> >-    time_t now = time(NULL);
> >+    time_t now;
> > 
> >-    if (now < 0)
> >-        now = r->request_time;
> >+    now = r->request_time;
> > 
> >     table_set(r->headers_out, "Last-Modified",
> >               gm_timestr_822(r->pool, (mtime > now) ? now : mtime));
> 
> -1 this part, +0 on the rest.  A new call to time() is here so that
> responses generated during the request handling can be simultaneously
> cached while allowing future conditional GETs to result in a 304 response.
> In other words, RobH needed it because the request handler is slow and
> the last line above would cause the delivered Last-Modified to be less
> than the actual modification date of a dynamically generated response.

Excellent memory Roy.

Might be worth adding some comments to explain why this is necessary.

ndex: http_protocol.c
===================================================================
RCS file: /imdb/cvs/apache/src/http_protocol.c,v
retrieving revision 1.34
diff -u -r1.34 http_protocol.c
--- http_protocol.c     1997/07/31 11:10:48     1.34
+++ http_protocol.c     1997/08/03 11:38:50
@@ -350,7 +350,15 @@
 {
     char *etag, weak_etag[MAX_STRING_LEN];
     char *if_match, *if_modified_since, *if_unmodified, *if_nonematch;
-    time_t now = time(NULL);
+    time_t now;
+
+    /* Check the time now; if the response has been created on demand then
+     * it might be newer than the time the request started and clients will
+     * be given an older Last-modified time than they need, resulting in
+     * if-modified-since GETs failing to respond "304 Not Modified" when
+     * they should.
+     */
+    now = time(NULL);
 
     if (now < 0)
         now = r->request_time;




I create files on-the-fly and send them back. Often they appear a second
newer than when the request started.

Dunno if I still have that problem but it's a hidden gotcha that's worth
preventing.




Mime
View raw message