Update docs and comment: the unique id is now 24 characters, not 19

Submitted by: Takashi Sato <takashi lans-tv com>, Stefan Fritsch
PR: 36269

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@981084 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/docs/manual/mod/mod_unique_id.xml b/docs/manual/mod/mod_unique_id.xml
index fbc740c4dd93036c9e94b2322981edd383ca75f7..51117801418696c8474e4440c0ce61204f5540e9 100644 (file)
--- a/docs/manual/mod/mod_unique_id.xml
+++ b/docs/manual/mod/mod_unique_id.xml
@@ -82,7 +82,10 @@ identifier for each request</description>
     <p>Given those assumptions, at a single point in time we can
     identify any httpd process on any machine in the cluster from
     all other httpd processes. The machine's IP address and the pid
-    of the httpd process are sufficient to do this. So in order to
+    of the httpd process are sufficient to do this. A httpd process
+    can handle multiple requests simultaneously if you use a
+    multi-threaded MPM. In order to identify threads, we use a thread
+    index Apache httpd uses internally. So in order to
     generate unique identifiers for requests we need only
     distinguish between different points in time.</p>
 
@@ -152,11 +155,13 @@ identifier for each request</description>
     even still, if you're running NTP then your UTC time will be
     correct very shortly after reboot.</p>
 
+    <!-- FIXME: thread_index is unsigned int, so not always 32bit.-->
     <p>The <code>UNIQUE_ID</code> environment variable is
-    constructed by encoding the 112-bit (32-bit IP address, 32 bit
-    pid, 32 bit time stamp, 16 bit counter) quadruple using the
+    constructed by encoding the 144-bit (32-bit IP address, 32 bit
+    pid, 32 bit time stamp, 16 bit counter, 32 bit thread index)
+    quadruple using the
     alphabet <code>[A-Za-z0-9@-]</code> in a manner similar to MIME
-    base64 encoding, producing 19 characters. The MIME base64
+    base64 encoding, producing 24 characters. The MIME base64
     alphabet is actually <code>[A-Za-z0-9+/]</code> however
     <code>+</code> and <code>/</code> need to be specially encoded
     in URLs, which makes them less desirable. All values are
@@ -182,8 +187,7 @@ identifier for each request</description>
     issuing the new encodings.</p>
 
     <p>This we believe is a relatively portable solution to this
-    problem. It can be extended to multithreaded systems like
-    Windows NT, and can grow with future needs. The identifiers
+    problem. The identifiers
     generated have essentially an infinite life-time because future
     identifiers can be made longer as required. Essentially no
     communication is required between machines in the cluster (only

diff --git a/modules/metadata/mod_unique_id.c b/modules/metadata/mod_unique_id.c
index fe4252b48e0168cdad651158615d343ed379d703..ef7430196677715646de97e8db9b66bacadd75d2 100644 (file)
--- a/modules/metadata/mod_unique_id.c
+++ b/modules/metadata/mod_unique_id.c
@@ -79,8 +79,8 @@ typedef struct {
  * saving cpu cycles.  The counter is never reset, and is used to permit up to
  * 64k requests in a single second by a single child.
  *
- * The 112-bits of unique_id_rec are encoded using the alphabet
- * [A-Za-z0-9@-], resulting in 19 bytes of printable characters.  That is then
+ * The 144-bits of unique_id_rec are encoded using the alphabet
+ * [A-Za-z0-9@-], resulting in 24 bytes of printable characters.  That is then
  * stuffed into the environment variable UNIQUE_ID so that it is available to
  * other modules.  The alphabet choice differs from normal base64 encoding
  * [A-Za-z0-9+/] because + and / are special characters in URLs and we want to