DO NOT REPLY New: - Problem with ETags between 32-bit and 64-bit architectures.

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=40
064>.
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: bugshttpd.apache.org
        ReportedBy: ross.heritagegmail.com
                CC: ross.heritagegmail.com


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=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: bugs-unsubscribehttpd.apache.org
For additional commands, e-mail: bugs-helphttpd.apache.org

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=40
064>.
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


jortonredhat.com changed:

           What    |Removed                     |Added
------------------------------------------------------------
----------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From jortonredhat.com  2007-03-12 08:15 -------
Committed: 
http://svn.apache.org/viewvc?view=rev&rev=517238 -
thanks for the report.

I'm not sure whether it would be a good idea to merge this
into 2.2.x; it could
break working 32-bit-only shops by having different 2.2.x
releases generate
different etags across a server farm.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: bugs-unsubscribehttpd.apache.org
For additional commands, e-mail: bugs-helphttpd.apache.org