You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Cliff Woolley <jw...@virginia.edu> on 2002/05/03 05:25:00 UTC
Re: if-modified-since field in request not handled correctly
On 3 May 2002 bugzilla@apache.org wrote:
> There seems to be an error in the handling of If-Modified-Since.
> Steps to reproduce:
> 1. Send the following request to www.dawnorchid.com:
>
> GET / HTTP/1.1
> Host: www.dawnorchid.com
>
> Resulting header is
>
> HTTP/1.1 200 OK
> Date: Sat, 04 May 2002 02:07:27 GMT
> Server: Apache/2.0.35 (Win32) PHP/4.2.0
> Last-Modified: Mon, 29 Apr 2002 07:58:14 GMT
>
> 2. Send another request for the same page, using the above timestamp in an If-
> Modified-Since field.
>
> GET / HTTP/1.1
> Host: www.dawnorchid.com
> If-Modified-Since: Mon, 29 Apr 2002 07:58:14 GMT
>
> Expected result: a 304 Not Modified response.
> Actual result: a 200 OK response with the full HTML page.
>
> If I change the time in the If-Modified-Since field to one second later
> (07:58:15 instead of 07:58:14), the expected 304 Not Modified response is
> returned.
Hmm.. the related code seems to be this snippet from http_protocol.c:
else if ((r->method_number == M_GET)
&& ((if_modified_since =
apr_table_get(r->headers_in,
"If-Modified-Since")) != NULL)) {
apr_time_t ims = apr_date_parse_http(if_modified_since);
if ((ims >= mtime) && (ims <= r->request_time)) {
return HTTP_NOT_MODIFIED;
}
}
return OK;
Which *looks* okay. My best guess is that, since we're comparing
apr_time_t's, maybe mtime includes some number of microseconds and thus is
greater than the ims for the same second. Does that sound reasonable? If
so, I guess we need to divide ims, mtime, and r->request_time by
APR_USEC_PER_SEC before comparison.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: if-modified-since field in request not handled correctly
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, May 02, 2002 at 11:25:00PM -0400, Cliff Woolley wrote:
> Which *looks* okay. My best guess is that, since we're comparing
> apr_time_t's, maybe mtime includes some number of microseconds and thus is
> greater than the ims for the same second. Does that sound reasonable? If
> so, I guess we need to divide ims, mtime, and r->request_time by
> APR_USEC_PER_SEC before comparison.
Yeah. HTTP/1.1 (section 3.3.1) only allows for second resolution,
so this seems the only way we can be RFC-compliant. -- justin
Re: if-modified-since field in request not handled correctly
Posted by Cliff Woolley <jw...@virginia.edu>.
On Thu, 2 May 2002, Cliff Woolley wrote:
> Which *looks* okay. My best guess is that, since we're comparing
> apr_time_t's, maybe mtime includes some number of microseconds and thus is
> greater than the ims for the same second. Does that sound reasonable? If
> so, I guess we need to divide ims, mtime, and r->request_time by
> APR_USEC_PER_SEC before comparison.
Upon further investigation, this definitely seems a likely possibility on
Win32. On Unix, the mtime will always have zero usecs (because it starts
out as a time_t and gets multiplied by APR_USEC_PER_SEC. On Win32,
however, mtime comes in from the OS as a FILETIME, which could potentially
include a nonzero number of usecs. Boom.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA