CANDIDATE] libapreq 1.34-RC4
*ping*
I don't actually see a vote from Steeve - just an advisory that it seems
OK. I did vote +1, and am ready to roll (after having a baby boy +
getting the flu twice; it's been a busy month ;)) as soon as I see a 3rd
binding vote.
Since steevehay does seem
Steve Hay wrote:
I didn't vote because AFAIK I don't actually have a vote. I have commit
access, but I'm not a PMC member and therefore have no vote. Is that
correct?
You're not ? mumble grumble.
--
1024D/DB9B8C1C B90B
- Original Message
From: Steve Hay steve...@planit.com
To: Issac Goldstand mar...@beamartyr.net
Cc: APREQ List apreq-dev@httpd.apache.org
Sent: Wednesday, January 7, 2009 8:54:48 AM
Subject: RE: [RELEASE CANDIDATE] libapreq 1.34-RC4
I didn't vote because AFAIK I don't actually
Issac Goldstand wrote:
Yay! That makes just a 1.5 year release cycle ;)
Me. Thought i might be slow.
--
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollu...@p6m7g8.com) c:
Philip M. Gollucci wrote:
Issac Goldstand wrote:
http://people.apache.org/~issac/libapreq-1.34-RC4.tar.gz
Unit tests blow up spectacularly on solaris 2.10 but I don't think we
support that and is related to Request.so failing to load.
It does compile.
I'll get a freebsd test for some sanity
Steve Hay wrote:
Issac Goldstand wrote:
The apreq developers are planning a maintenance release of
libapreq1. This version primarily addresses an issue noted
with FireFox 2.0 truncating file uploads in SSL mode.
Additionally, the memory allocation algorithm for multipart
requests has been
The apreq developers are planning a maintenance release of
libapreq1. This version primarily addresses an issue noted
with FireFox 2.0 truncating file uploads in SSL mode.
Additionally, the memory allocation algorithm for multipart
requests has been improved.
Please give the tarball at
