On 21 Dec 2009, at 07:22, Ruediger Pluem wrote:
Why bytes_handled - 1 and not bytes_handled?
Terminating null.
(we know the last byte actually handled was LF because we got a line-end).
--
Nick Kew
-Original Message-
From: nicholas@sun.com On
Behalf Of Nick Kew
Sent: Montag, 21. Dezember 2009 10:36
To: dev@httpd.apache.org
Subject: Re: svn commit: r892678 - in /httpd/httpd/trunk:
CHANGES server/protocol.c
On 21 Dec 2009, at 07:22, Ruediger Pluem wrote:
Why
-Original Message-
From: nicholas@sun.com [mailto:nicholas@sun.com] On
Behalf Of Nick Kew
Sent: Montag, 21. Dezember 2009 10:36
To: dev@httpd.apache.org
Subject: Re: svn commit: r892678 - in /httpd/httpd/trunk:
CHANGES server/protocol.c
On 21 Dec 2009, at 07:22,
Does anyone know how to unsubscribe from this list?
I have sent email to the unsubscribe link on apache.org several times.
Yet, I still receive numerous emails that are cluttering my overcrowded
inbox.
Can someone please help me to unsubscribe?
Michele
-Original Message-
From:
I am not overly concerned, but still a bit frustrated. The hours I spend on
this project are probably minimal compared to yours as a dev (me humble
tester/porter), but if you help me learn how the components used to assemble
these packages (configure, auto*, libtool, and whatever else) you will
Hi,
The ContentDigest option does not seem to convert the MD5 to network
byte order before doing base64 encoding. The RFC says:
The output of the MD5 algorithm is a 128 bit digest. When viewed in
network byte order (big-endian order), this yields a sequence of 16
octets of binary data. These
On Mon, Dec 21, 2009 at 2:20 PM, Deepak Nagaraj n.dee...@gmail.com wrote:
Hi,
The ContentDigest option does not seem to convert the MD5 to network
byte order before doing base64 encoding. The RFC says:
It's 16 bytes, what reordering did you want to do? Byte order only
applies to stuff larger
On Mon, Dec 21, 2009 at 7:02 PM, Olaf van der Spek olafvds...@gmail.com wrote:
On Mon, Dec 21, 2009 at 2:20 PM, Deepak Nagaraj n.dee...@gmail.com wrote:
Hi,
The ContentDigest option does not seem to convert the MD5 to network
byte order before doing base64 encoding. The RFC says:
It's 16
On Mon, Dec 21, 2009 at 3:07 PM, Deepak Nagaraj n.dee...@gmail.com wrote:
It's 16 bytes, what reordering did you want to do? Byte order only
applies to stuff larger than individual bytes.
The RFC considers it as a 128-bit digest (=number). It can be
divided into 16 bytes in either host order
Hi,
Today I stepped over the upload corruption bug affecting the current 2.3.4
version of mod_fcgid:
http://drupal.org/node/635270
http://www.mail-archive.com/dev@httpd.apache.org/msg46230.html
As this is a rather serious issue, I wanted to ask if you can push a new
release of mod_fcgid. I
On Mon, Dec 21, 2009 at 5:07 PM, Deepak Nagaraj n.dee...@gmail.com wrote:
AFAIK that really doesn't apply. It's not an int, it's a 16-byte
'array' that shouldn't be reordered.
You're right about MD5. I checked the MD5-algorithm RFC (1321). It
specifies that the digest is generated in
On Mon, Dec 21, 2009 at 11:02 PM, Olaf van der Spek
olafvds...@gmail.com wrote:
But on the other hand, HTTP Content-MD5 header RFC (1864) explicitly
mentions network byte ordering as I originally quoted. Being a
standards-compliant HTTP server, IMO, we should be doing whatever the
RFC says,
On Mon, Dec 21, 2009 at 6:35 PM, Deepak Nagaraj n.dee...@gmail.com wrote:
On Mon, Dec 21, 2009 at 11:02 PM, Olaf van der Spek
olafvds...@gmail.com wrote:
But on the other hand, HTTP Content-MD5 header RFC (1864) explicitly
mentions network byte ordering as I originally quoted. Being a
n...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=893027view=rev
Log:
(re)-introduce -T commandline option to suppress documentroot check at startup
PR 41887
This must be be conditioned on a case-sensitive filesystem; otherwise a very
loud emit should be broadcast warning that
On Mon, Dec 21, 2009 at 2:39 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
-Original Message-
From: nicholas@sun.com [mailto:nicholas@sun.com] On
Behalf Of Nick Kew
Sent: Montag, 21. Dezember 2009 10:36
To: dev@httpd.apache.org
Subject: Re: svn commit:
Paul Querna wrote:
On Mon, Dec 21, 2009 at 2:39 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
Please reconsider and fix.
Done, thanks.
I am also slightly concerned about changing the behavoir of
ap_rgetline_core in regards to embedded NULL bytes, since this is not
just
On Mon, Dec 21, 2009 at 4:41 PM, Nick Kew n...@webthing.com wrote:
Paul Querna wrote:
On Mon, Dec 21, 2009 at 2:39 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
Please reconsider and fix.
Done, thanks.
I am also slightly concerned about changing the behavoir of
On Mon, Dec 21, 2009 at 11:07 PM, Olaf van der Spek
olafvds...@gmail.com wrote:
But on the other hand, HTTP Content-MD5 header RFC (1864) explicitly
mentions network byte ordering as I originally quoted. Being a
standards-compliant HTTP server, IMO, we should be doing whatever the
RFC says,
18 matches
Mail list logo
