DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<
http://issues.apache.org/bugzilla/show_bug.cgi?id=40064>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40064 Summary: Problem with ETags between 32-bit and 64-bit
architectures.
Product: Apache httpd-2
Version: 2.0.58
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Core
AssignedTo:
bugs@...
ReportedBy:
ross.heritage@...
CC:
ross.heritage@...
The last modified date stored in r->mtime is of type apr_int64_t.
When this is used to build up the ETag in modules/http/http_protocol.c (in
ap_make_etag), this variable is cast to an unsigned long prior to the
converion to hex.
next = etag_ulong_to_hex(next, (unsigned long)r->mtime);
On a 32-bit architecture, this loses the first 32-bits of the number, so the
resulting hex string is only 8 characters long, and does not accuratly reflect
the last-modified time.
On a 64-bit architecture, the cast retains all 64 bits (or more likely its
casting a 128-bit number down to 64-bits), so the resulting hex value is
correct.
This is a big problem for us at the BBC as we now have a mixture of 32-bit and
64-bit machines (AMD Opteron vs. Intel Xeon).
The problem also seems to exist in the latest Apache 2.2 build, although the
ETag code has been extracted to the file modules/http/http_etag.c
Suggested fix:
Change the etag_ulong_to_hex function so that it only ever pushes the last 8
hex characters on to *next. This is not ideal, as the resulting hex is not
representative of the last-modified date, but I would be surprised if this
were to bite anyone.
--
Configure bugmail:
http://issues.apache.org/bugzilla/userprefs.cgi?tab=email------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail:
bugs-unsubscribe@...
For additional commands, e-mail:
bugs-help@...
