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: [email protected] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
