On 07/10/2013 06:24 PM, Joe Orton wrote:
On Tue, Jul 09, 2013 at 11:02:18PM +0200, Stefan Fritsch wrote:
On Tuesday 09 July 2013, Joe Orton wrote:
On Tue, Jul 09, 2013 at 10:00:19AM +0200, Jan Kaluza wrote:
I agree 20 bytes could be too much. I have changed my patch to
have only 10 bytes long
On Tue, Jul 09, 2013 at 11:02:18PM +0200, Stefan Fritsch wrote:
On Tuesday 09 July 2013, Joe Orton wrote:
On Tue, Jul 09, 2013 at 10:00:19AM +0200, Jan Kaluza wrote:
I agree 20 bytes could be too much. I have changed my patch to
have only 10 bytes long root. I will check the Daniel's
On 07/06/2013 01:58 AM, Stefan Fritsch wrote:
On Wednesday 26 June 2013, Jan Kaluža wrote:
currently mod_unique_id uses apr_gethostname(...) and PID pair as a
base to generate unique ID. The way how it's implemented brings
some problems:
1. For IPv6-only hosts it uses low-order bits of IPv6
On Tue, Jul 09, 2013 at 10:00:19AM +0200, Jan Kaluza wrote:
I agree 20 bytes could be too much. I have changed my patch to have
only 10 bytes long root. I will check the Daniel's ideas mentioned
in another mail in this thread and try to implement it, but if we
are going to do it my way, I
On Sunday 07 July 2013, Daniel Lescohier wrote:
Another option:
typedef struct {
apr_uint32_t stamp;
apr_uint32_t counter;
apr_uint16_t stamp_fraction;
char root[ROOT_SIZE];
} unique_id_rec;
where ROOT_SIZE=8, and stamp_fraction is set on every request to
On Tuesday 09 July 2013, Joe Orton wrote:
On Tue, Jul 09, 2013 at 10:00:19AM +0200, Jan Kaluza wrote:
I agree 20 bytes could be too much. I have changed my patch to
have only 10 bytes long root. I will check the Daniel's ideas
mentioned in another mail in this thread and try to implement
Another option:
typedef struct {
apr_uint32_t stamp;
apr_uint32_t counter;
apr_uint16_t stamp_fraction;
char root[ROOT_SIZE];
} unique_id_rec;
where ROOT_SIZE=8, and stamp_fraction is set on every request to
htons(r-request_time 0x).
The child will be initialized with 12
Actually, for stamp_fraction, one should choose either:
r-request_time 0x /* microseconds modulus 65536 */
apr_uint16_t ui16;
htons(ui16 = apr_time_usec(r-request_time) 4) /* fraction of a second
with denominator 62500 */
On Sun, Jul 7, 2013 at 7:32 AM, Daniel Lescohier
Ah, I missed that. I see it's in the doxygen docs for the random module.
However, the sources aren't under random/, they're under misc/. I was
switching between the doxygen docs and looking at the sources; maybe when I
was looking for it, I missed it because the sources were under misc/.
For
On Wednesday 26 June 2013, Jan Kaluža wrote:
currently mod_unique_id uses apr_gethostname(...) and PID pair as a
base to generate unique ID. The way how it's implemented brings
some problems:
1. For IPv6-only hosts it uses low-order bits of IPv6 address as if
they were unique, which is
On Wednesday 26 June 2013, Daniel Lescohier wrote:
When I looked into the ap random functions, I didn't like the
implementation, because I didn't see anywhere in the httpd codebase
that entropy is periodically added to the entropy pool. After
reading the details of how the Linux entropy pool
Hi,
currently mod_unique_id uses apr_gethostname(...) and PID pair as a base
to generate unique ID. The way how it's implemented brings some problems:
1. For IPv6-only hosts it uses low-order bits of IPv6 address as if they
were unique, which is wrong.
2. It relies on working DNS. It can
We have an internal custom Apache module that generates UUIDs; it's using a
legacy format that we need for our application. A few months ago, I was
upgrading it to Apache 2.4, and I worked on modifying the UUID generator
function, so that some of the bytes are random (including replacing the 4
13 matches
Mail list logo
