Bug 37064 - wrong timestamp value in UNIQUE_ID on mod_unique_id in Apache2.0.54
Summary: wrong timestamp value in UNIQUE_ID on mod_unique_id in Apache2.0.54
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_unique_id (show other bugs)
Version: 2.0.61
Hardware: Other Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk, PatchAvailable
Depends on:
Blocks:
 
Reported: 2005-10-13 09:17 UTC by Kobayashi
Modified: 2008-06-02 14:27 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kobayashi 2005-10-13 09:17:13 UTC
Dear all,

I found the value of timestamp in UNIQUE_ID is always wrong in my environment. 
I decoded the value and confirmed that the value was be completely different 
from real one, it didn't has continuousness for requested time, and it looked 
like random numbers.

The reason comes from the difference from variable type. i.e. the variable 
type of unique_id_rec.stamp is a 'unsigned int' but a type of 
request_rec.request_time is 'apr_time_t', which is apr_int64_t. So, timestamp 
results in the value set mainly microsecond part.

The following change will be needed to use correct timestamp.

307c307
<     new_unique_id.stamp = htonl((unsigned int)r->request_time);
---
>     new_unique_id.stamp = htonl((unsigned int)(r-
>request_time/APR_USEC_PER_SEC));

(*one line respectively*)


Thank you.


**FYI:  'requested_time' is set as follows
--in httpd-2.0.52/srclib/apr/time/unix/time.c---
APR_DECLARE(apr_time_t) apr_time_now(void)
{
    struct timeval tv;
    gettimeofday(&tv, NULL);
    return tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
}
Comment 1 Matthias Lehr 2007-11-19 08:04:09 UTC
This Bug still exists in 2.2.6 and 2.0.61

Timestamp wraps around in 4292 seconds, 
so in worst case you will get the same 
"unique_id" after 72 minutes.

The correct handling will allow easier
extraction of the timestamp and better debugging 
because you need to look at forensic_log only
Comment 2 Matthias Lehr 2007-11-19 08:04:29 UTC
This Bug still exists in 2.2.6 and 2.0.61

Timestamp wraps around in 4292 seconds, 
so in worst case you will get the same 
"unique_id" after 72 minutes.

The correct handling will allow easier
extraction of the timestamp and better debugging 
because you need to look at forensic_log only
Comment 3 Ruediger Pluem 2007-11-19 13:09:28 UTC
Committed to trunk as r596448
(http://svn.apache.org/viewvc?rev=596448&view=rev). Thanks for the reminder.
Comment 4 Takashi Sato 2008-05-31 01:37:12 UTC
Please consider backporting.
This is low hanging fruit.
Comment 5 Ruediger Pluem 2008-05-31 02:22:48 UTC
Proposed for backport to 2.2.x as r661991 (http://svn.apache.org/viewvc?view=rev&revision=661991).
Comment 6 Ruediger Pluem 2008-06-02 14:27:26 UTC
Backported as r662575 (http://svn.apache.org/viewvc?rev=662575&view=rev).