On Thu, Mar 04, 2004 at 07:41:54AM +0100, André Malo wrote:
I'd prefer the %{SSL:...} variant and using ssl_var_lookup_ssl. All other
Agreed. It makes sense to me to make a specific point out of where those
variables came from.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' -
On Thu, Mar 04, 2004 at 07:41:54AM +0100, André Malo wrote:
* Mathihalli, Madhusudan [EMAIL PROTECTED] wrote:
Here's a slightly modified version of Joe's patch to
- not segfault if rewrite_ssl_var_lookup is not available (mod_ssl not
loaded)- use SSL environment variables as
Justin Erenkrantz wrote:
--On Wednesday, March 3, 2004 12:24 PM +0100 Henri Gomez
[EMAIL PROTECTED] wrote:
To resume you :
- remove translate
- move translate code to map_storage
Did I understand correctly ?
Yes, I think that'll work. -- justin
Ok, Jean-Frederic is working on what you
* Joe Orton [EMAIL PROTECTED] wrote:
I'm not really convinced about using ssl_var_lookup_ssl: that function
does not handle the HTTPS variable, and it would be potentially
confusing to users and hard to document since only some subset of the
SSL variables could be used. (it would also need a
On Thu, Mar 04, 2004 at 11:08:25AM +0100, André Malo wrote:
* Joe Orton [EMAIL PROTECTED] wrote:
I'm not really convinced about using ssl_var_lookup_ssl: that function
does not handle the HTTPS variable, and it would be potentially
confusing to users and hard to document since only some
On Tue, Mar 02, 2004 at 10:11:06AM -0800, Stas Bekman wrote:
Justin Erenkrantz wrote:
...
Correct. Because the EOS is generated by the request-level protocol
handler (HTTP_IN). That's exactly how it is designed. If a connection
input filter saw EOS, it'd signal end-of-connection not
On Mon, Mar 01, 2004 at 05:49:52PM -, [EMAIL PROTECTED] wrote:
ake 2004/03/01 09:49:52
Modified:.libhttpd.dsp
Log:
add eoc_bucket.c to project
I'm not qualified to review Win32 changes but did you mean to remove
/incremental:no from the linker flags here as
Maybe
we should put the HTTPS check into an own function (we could use %{HTTPS} in
mod_rewrite then). That way, other modules, that want to check (only) HTTPS,
also don't need to run though all the mess of ssl_var_lookup.
I'm not familiar with mod_ssl internals, but is there any reason we
If you have a concrete example of something that needs to query the state,
then we can examine whether it should hook into the processing
differently. I bet there is a different hook or approach that can avoid a
query of the state.
I think where stas is headed are cases like ryan's
At 09:09 AM 3/4/2004, Joe Orton wrote:
On Mon, Mar 01, 2004 at 05:49:52PM -, [EMAIL PROTECTED] wrote:
ake 2004/03/01 09:49:52
Modified:.libhttpd.dsp
Log:
add eoc_bucket.c to project
I'm not qualified to review Win32 changes but did you mean to remove
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]
[SNIP]
I'm not familiar with mod_ssl internals, but is there any
reason we can't
move subprocess_env population to something early like
post-read-request?
as a per-connection thingy, HTTPS ought to be know before
On Sat, Feb 21, 2004 at 11:00:25AM +, Alexis Huxley wrote:
I'm running apache 2.1dev, and I've posted to the -user list with
no response, so now I'm a bit stuck as to where next to try, so I'm
posting here. Apologies if this is the wrong place.
The bug is that the POD code is doing a name
At 09:55 AM 3/4/2004, Greg Marr wrote:
/incremental:no is the default, and MSDev will at times remove flags that it finds
redundant, even ones that it added itself. It's a bit schizophrenic like that.
uh wrong. with /debug incremental yes is the default but you have
to pound it into the
Not to mention the kr calling convention...
# diff -u ab.old.c ab.c
--- ab.old.cThu Mar 4 12:32:21 2004
+++ ab.cThu Mar 4 12:32:52 2004
@@ -558,6 +558,7 @@
BIO *bio;
X509 *x509cert;
{
+#define BUFSIZE 64
X509_NAME *dn;
char buf[64];
One more thing.
Can someone explain this SSL bit for me?
This seems to be an uninit var invocation for pollresults?
const apr_pollfd_t *pollresults;
-snip
if (ssl == 1)
status = APR_SUCCESS;
else
#endif
status = apr_pollset_poll(readbits, aprtimeout, n,
At 12:00 PM 3/4/2004, William A. Rowe, Jr. wrote:
At 09:55 AM 3/4/2004, Greg Marr wrote:
/incremental:no is the default, and MSDev will at times remove
flags that it finds redundant, even ones that it added
itself. It's a bit schizophrenic like that.
uh wrong. with /debug incremental yes
At 12:04 PM 3/4/2004, Greg Marr wrote:
At 12:00 PM 3/4/2004, William A. Rowe, Jr. wrote:
At 09:55 AM 3/4/2004, Greg Marr wrote:
/incremental:no is the default, and MSDev will at times remove flags that it finds
redundant, even ones that it added itself. It's a bit schizophrenic like that.
One more thing.
Can someone explain this SSL bit for me?
This seems to be an uninit var invocation for pollresults?
const apr_pollfd_t *pollresults;
-snip
if (ssl == 1)
status = APR_SUCCESS;
else
#endif
status = apr_pollset_poll(readbits, aprtimeout, n,
Geoffrey Young wrote:
If you have a concrete example of something that needs to query the state,
then we can examine whether it should hook into the processing
differently. I bet there is a different hook or approach that can avoid a
query of the state.
I think where stas is headed are cases
Sander Temme wrote:
One more thing.
Can someone explain this SSL bit for me?
This seems to be an uninit var invocation for pollresults?
const apr_pollfd_t *pollresults;
-snip
if (ssl == 1)
status = APR_SUCCESS;
else
#endif
status = apr_pollset_poll(readbits, aprtimeout,
At 01:33 PM 3/4/2004, William A. Rowe, Jr. wrote:
At 12:04 PM 3/4/2004, Greg Marr wrote:
At 12:00 PM 3/4/2004, William A. Rowe, Jr. wrote:
At 09:55 AM 3/4/2004, Greg Marr wrote:
/incremental:no is the default, and MSDev will at times remove
flags that it finds redundant, even ones that it added
Thanks for the quick response -- sorry I've been slow getting back to
you. Yes, the attached patch does seem to fix 1.3.X. It'd be great if
it got rolled into the next point release.
On Thu, Feb 26, 2004 at 09:18:02AM -0500, Geoffrey Young wrote:
Will Lowe wrote:
It looks like byte-range
On Thu, Mar 04, 2004 at 01:48:15PM -0500, Aryeh Katz wrote:
I'm not quite sure how to submit a patch to bugzilla, so can someone
please take care of the following for me.
In addition, and corrections/better ways would be greatly appreciated.
That one is actually fixed on HEAD though ab's SSL
I would like to resurrect an old discussion. About a year and half
ago rbb and wrowe committed a patch for mod_ssl to provide the SSLEngine
upgrade capability. It seems that one of the reasons for not back
porting it to the 2.0 tree was because there weren't really any clients
that supported
Will Lowe wrote:
Thanks for the quick response -- sorry I've been slow getting back to
you. Yes, the attached patch does seem to fix 1.3.X. It'd be great if
it got rolled into the next point release.
ok, I'll try and guide it through the process.
--Geoff
(Sorry for the off-topic post - it was suggested to me that I post here
and see if there was any interest...)
Hi - I'm a CS researcher who does research in groupware and distributed
systems. I'm writing because I would like to interview some httpd
developers to find out how people in
flood STATUS: -*-text-*-
Last modified at [$Date: 2003/07/01 20:55:12 $]
Release:
1.0: Released July 23, 2002
milestone-03: Tagged January 16, 2002
ASF-transfer: Released July 17, 2001
milestone-02: Tagged August 13,
httpd-test/perl-framework STATUS: -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]
Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
framework failed)
* change existing tests that frob the DocumentRoot (e.g.,
28 matches
Mail list logo
