DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33381.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32658.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Gregory (Grisha) Trubetskoy wrote:
On Wed, 10 Aug 2005, Jim Gallacher wrote:
Compilation fails with the following:
requestobject.c: In function 'request_tp_dealloc':
requestobject.c:1482: warning: implicit declaration of function
'request_tp_clear'
This looks like a bug - I guess GCC 3
Jim Martinez wrote:
Who maintains http://httpd.apache.org/test/ ?
There's a image on it that reads ApacheCon Europe 2005 that links to the
ApacheCon US 2005 (via a redirect).
ApacheCon Europe 2005 was, according to the web site, held around July
18th, 2005. Most likely the image should be
On Wed, Aug 10, 2005 at 03:38:17PM -0700, Justin Erenkrantz wrote:
--On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
O.k., I've merged our two patches, but I've changed a few things, tell
me if there's anothing you think is wrong;
Would you mind writing up a
On Wednesday 10 August 2005 07:44, Nick Kew wrote:
If noone objects I'll commit the Trunk patch and propose the
2.0 patch for backport.
OK, I've just proposed the 2.0-backport in STATUS.
I would add a couple of comments to this.
Firstly, this is in production use at the Client who first drew
I couldn't successfully compile Apache (2.1.6-alpha) with SLES9
(2.6.5-7.97-smp, 64bit).
The error is:
...-lrt -lcrypt -lpthread -ldl -lgdbm -ldb-4.2 /usr/lib/libexpat.la
/root/huxuekun/httpd-2.1.6-alpha/srclib/apr/libapr-1.la -lrt -lcrypt
-lpthread -ldl
/usr/lib/libexpat.so: could not read
Hu, Xuekun wrote:
I couldn't successfully compile Apache (2.1.6-alpha) with SLES9
(2.6.5-7.97-smp, 64bit).
The error is:
...-lrt -lcrypt -lpthread -ldl -lgdbm -ldb-4.2 /usr/lib/libexpat.la
/root/huxuekun/httpd-2.1.6-alpha/srclib/apr/libapr-1.la -lrt -lcrypt
-lpthread -ldl
Parin Shah said:
- I played with it to make it work without conn_rec, but it doesnt
soudn very clean to me . the main reason is request_rec itself needs
conn_rec and also other conn_rec variables like lookup defaults. so
even if we could make it work (which I am not 100% sure that it would
On Thu, Aug 11, 2005 at 03:06:51PM +0200, Andreas Steinmetz wrote:
Hu, Xuekun wrote:
...
Since this is 64 bit, libexpat.la should be reference to /usr/lib64
instead of /usr/lib.
...
Since some Linux (64bit) distributions maybe have lib/libexpat.la file,
so I put the lib64 check early.
On Wed, 10 Aug 2005, Jim Gallacher wrote:
Compilation fails with the following:
requestobject.c: In function 'request_tp_dealloc':
requestobject.c:1482: warning: implicit declaration of function
'request_tp_clear'
This looks like a bug - I guess GCC 3 defaulted to static for implicitely
On Thu, 11 Aug 2005, Gregory (Grisha) Trubetskoy wrote:
On Wed, 10 Aug 2005, Jim Gallacher wrote:
It's easy enough to fix (and I will) by adding a function prototype
What you probably mean to say is that they do not have forward
declarations
Having googled this a bit, function
--On August 10, 2005 11:36:43 PM + [EMAIL PROTECTED] wrote:
Author: niq
Date: Wed Aug 10 16:36:39 2005
New Revision: 231355
URL: http://svn.apache.org/viewcvs?rev=231355view=rev
Log:
Fix ProxyPassReverse family to work correctly in Location
This commit broke the build.
--On August 11, 2005 10:21:37 AM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
On Wed, Aug 10, 2005 at 03:38:17PM -0700, Justin Erenkrantz wrote:
--On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
O.k., I've merged our two patches, but I've changed a few
In a message dated 8/11/2005 12:42:35 PM Central Daylight Time, [EMAIL PROTECTED] writes:
The code will remove the header file and the disk file; but it also likely needs to go up a 'level' and remove all variants. Because if we get a 404 on a varied entity, it also means that all variants
Does this code from 2.1 in apr_proxy_http_request still make sense? Do we
not want to attempt to maintain the server connection anyway? Maybe I'm
missing some other logic...
/* strip connection listed hop-by-hop headers from the request */
/* even though in theory a connection: close
Justin Erenkrantz wrote:
Fix ProxyPassReverse family to work correctly in Location
This commit broke the build.
Aaargh! Careless cutpaste. Sorry. Fixed - thanks.
Please fix or revert. (I have no idea what you were trying to do.) --
See my posts on Fixing ProxyPassReverse.
--
On Thu, 11 Aug 2005 [EMAIL PROTECTED] wrote:
It is possible ( and legal? ) for a COS ( Content Origin Server ) to return
a '404' on one variant of an entity but not on another.
Regardless - it is quite a common thing to do.
Dw.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35669.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32658.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Title: Message
Would anyone be able
to tell me if Apache2 is FIPS certified? If I build OpenSSL with the FIPS
flag, is there anything else I have to do when building Apache with
OpenSSL? Thanks.
,
Josh.
Plenty. First, OpenSSL is -not- FIPS certified. It's in
the certification under test (CUT) phase, and no word of
exactly what will come of that phase. Second, you would
have to enable OpenSSL's fips-only mode, and stop using
all prohibited entropy, hashing and crypto.
The http project has a
[..cut..]
Thanks! I've committed this in r231486, r231487, and r231488. I re-split
them up to make it easier for people to review the commits.
However, there remains an issue in mod_disk_cache's remove_url: I don't think
it properly handles removing the Vary condition files. I went ahead
26 matches
Mail list logo
