Re: 2.0.48 startup crash
Robert La Ferla wrote: I added CookieName Apache to my conf and now I'm getting: [Thu Nov 27 11:12:06 2003] [crit] (17)File exists: unable to create scoreboard /myapachepath/logs/apache_runtime_status (name-based shared memory failure) Option 1: Remove the file and try again Option 2: Remove the shared memory segments with the ipcrm tool Option 3: Rename the file in the configuration Option 4: Reboot :) System V IPC :( -- ir. Kris Verbeeck Software Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Re: child process segfaults in reverse SSL proxy setup
I have created bugs 24029, 24030 and 24031 for the issues described in this thread. Joe Orton wrote: Hi Kris, On Wed, Oct 22, 2003 at 04:44:39PM +0200, Kris Verbeeck wrote: After several days of tracing through the mod_proxy/mod_ssl/OpenSSL code with gdb I now finally have a working setup with reverse proxy SSL client certificate authentication. I encountered two problems: 1) AFAICT, the documentation of the SSLProxyMachineCertificateFile is incorrect. The docs state: ... IMHO you should not put a bunch of CA certs in this file. The file should contain the SSL client certificate and its corresponding private key (by concatenating them in PEM-encoded format). I wonder if it can contain multiple certificates and keys? Yup, that's a documentation bug, this section should just talk about client certificates. Yes, you can put several client certs in a single file, just append certificate, key, certificate key, ... in PEM format. Adding the private key fixes the SIGSEGV from the original mail. 2) It also seems that the current code can not handle private keys that are passphrase protected. The key is never decrypted (there is no passphrase prompt) which results in a new SIGSEGV. Using a non-encrypted key fixes this second SIGSEGV. Can anyone confirm/deny this behaviour? If it can be confirmed, I will add two new bugs in bugzilla. Yes, that's definitely a real bug, nice work. For problem 2, can anyone give me some suggestions on how to solve this? ssl_engine_init.c needs to check that each loaded client cert has both an X509 cert and a private key; if not, it should give an error and not configure an incomplete X509_INFO structure. (ssl_engine_pphrase.c could also be extended to support decrypting the private keys used for the proxy, but I've not heard anyone screaming for that feature) Regards, joe -- ir. Kris Verbeeck Software Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Re: child process segfaults in reverse SSL proxy setup
After several days of tracing through the mod_proxy/mod_ssl/OpenSSL code
with gdb I now finally have a working setup with reverse proxy SSL client
certificate authentication.
I encountered two problems:
1) AFAICT, the documentation of the SSLProxyMachineCertificateFile is
incorrect. The docs state:
This directive sets the all-in-one file where you keep the
certificates of Certification Authorities (CAs) whose proxy
client certificates are used for authentication of the proxy
server to remote servers.
This referenced file is simply the concatenation of the
various PEM-encoded certificate files, in order of preference.
Use this directive alternatively or additionally to
SSLProxyMachineCertificatePath.
Example:
SSLProxyMachineCertificatePath /usr/local/apache/conf/ssl.crt/
IMHO you should not put a bunch of CA certs in this file. The file
should contain the SSL client certificate and its corresponding private
key (by concatenating them in PEM-encoded format). I wonder if it can
contain multiple certificates and keys?
Adding the private key fixes the SIGSEGV from the original mail.
2) It also seems that the current code can not handle private keys
that are passphrase protected. The key is never decrypted (there
is no passphrase prompt) which results in a new SIGSEGV. Using a
non-encrypted key fixes this second SIGSEGV.
Can anyone confirm/deny this behaviour? If it can be confirmed,
I will add two new bugs in bugzilla.
For problem 2, can anyone give me some suggestions on how to solve
this?
thx
Kris Verbeeck wrote:
Hi,
I have set up an Apache 2.0 reverse proxy that forwards incoming
requests over SSL to a back-end web server (also an Apache 2.0).
The back-end requires SSL client certificate authentication.
When firing a request, the reverse proxy child process segfaults.
The segfault occurs in the ssl_callback_proxy_cert() function
(ssl_engine_kernel.c) when calling the modssl_set_cert_info() macro.
This macro is defined as follows:
#define modssl_set_cert_info(info, cert, pkey) \
*cert = info-x509; \
X509_reference_inc(*cert); \
*pkey = info-x_pkey-dec_pkey; \
EVP_PKEY_reference_inc(*pkey)
When tracing trough the code with gdb the following values are
present in the local variables:
(gdb) p info
$4 = (struct X509_info_st *) 0x8236688
(gdb) p cert
No symbol cert in current context.
(gdb) p pkey
$5 = (struct evp_pkey_st **) 0xb26c
(gdb) p *info
$6 = {x509 = 0x8236bf0, crl = 0x0, x_pkey = 0x0, enc_cipher = {cipher
= 0x0,
iv = ú\024/KJh\207§}, enc_len = 0, enc_data = 0x0, references = 1}
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x08095b9d in ssl_callback_proxy_cert (ssl=0x0, x509=0xb268,
pkey=0xb26c) at ssl_engine_kernel.c:1592
1592modssl_set_cert_info(info, x509, pkey);
AFAICT, the problem is that the x_pkey field in the info structure
is NULL (the third line in the macro tries to access a field in
this x_pkey structure).
Has anybody else encountered a similar problem? Any suggestions on
how this can be solved?
Relevant part of reverse proxy configuration:
ProxyPass/proxyssl https://backend:444
ProxyPassReverse /proxyssl https://backend:444
SSLProxyEngine on
SSLProxyMachineCertificateFile conf/ssl/backend-client.crt
Relevant part of back-end SSL server configuration:
Listen 444
VirtualHost _default_:444
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile conf/ssl/server.crt
SSLCertificateKeyFile conf/ssl/server.key
SSLCACertificateFile conf/ssl/ca-bundle.crt
SSLVerifyClient require
/VirtualHost
Relevant part of Apache error_log:
[Thu Oct 16 07:18:41 2003] [debug] ssl_engine_kernel.c(1788): OpenSSL:
Loop: SSLv3 read server certificate request A
[Thu Oct 16 07:18:41 2003] [debug] ssl_engine_kernel.c(1788): OpenSSL:
Loop: SSLv3 read server done A
[Thu Oct 16 07:21:13 2003] [debug] ssl_engine_kernel.c(1554): Proxy
client certificate callback: (host:80) entered
[Thu Oct 16 07:21:55 2003] [debug] ssl_engine_kernel.c(1527): Proxy
client certificate callback: (host:80) found acceptable cert, sending
/C=BE/ST=...
[Thu Oct 16 07:31:44 2003] [notice] child pid 2983 exit signal
Segmentation fault (11)
--
ir. Kris Verbeeck
Software Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
Re: Can't use handler + reverse proxy
Matthieu Estrade wrote: I am actually using apache as a reverse proxy, and i am trying to use a handler with... and it doesn't work. When i setup my SetHandler on a local virtualhost, it works well, but when i setup it on a virtualhost doing reverse proxy, it's never called. any ideas ? IMHO, in teh reverse proxy case, the handler is mod_proxy. You'll have to solve this some other way I think. What exactly are you trying to accomplish with your handler? -- ir. Kris Verbeeck Software Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
child process segfaults in reverse SSL proxy setup
Hi,
I have set up an Apache 2.0 reverse proxy that forwards incoming
requests over SSL to a back-end web server (also an Apache 2.0).
The back-end requires SSL client certificate authentication.
When firing a request, the reverse proxy child process segfaults.
The segfault occurs in the ssl_callback_proxy_cert() function
(ssl_engine_kernel.c) when calling the modssl_set_cert_info() macro.
This macro is defined as follows:
#define modssl_set_cert_info(info, cert, pkey) \
*cert = info-x509; \
X509_reference_inc(*cert); \
*pkey = info-x_pkey-dec_pkey; \
EVP_PKEY_reference_inc(*pkey)
When tracing trough the code with gdb the following values are
present in the local variables:
(gdb) p info
$4 = (struct X509_info_st *) 0x8236688
(gdb) p cert
No symbol cert in current context.
(gdb) p pkey
$5 = (struct evp_pkey_st **) 0xb26c
(gdb) p *info
$6 = {x509 = 0x8236bf0, crl = 0x0, x_pkey = 0x0, enc_cipher = {cipher = 0x0,
iv = ú\024/KJh\207§}, enc_len = 0, enc_data = 0x0, references = 1}
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x08095b9d in ssl_callback_proxy_cert (ssl=0x0, x509=0xb268,
pkey=0xb26c) at ssl_engine_kernel.c:1592
1592modssl_set_cert_info(info, x509, pkey);
AFAICT, the problem is that the x_pkey field in the info structure
is NULL (the third line in the macro tries to access a field in
this x_pkey structure).
Has anybody else encountered a similar problem? Any suggestions on
how this can be solved?
Relevant part of reverse proxy configuration:
ProxyPass/proxyssl https://backend:444
ProxyPassReverse /proxyssl https://backend:444
SSLProxyEngine on
SSLProxyMachineCertificateFile conf/ssl/backend-client.crt
Relevant part of back-end SSL server configuration:
Listen 444
VirtualHost _default_:444
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile conf/ssl/server.crt
SSLCertificateKeyFile conf/ssl/server.key
SSLCACertificateFile conf/ssl/ca-bundle.crt
SSLVerifyClient require
/VirtualHost
Relevant part of Apache error_log:
[Thu Oct 16 07:18:41 2003] [debug] ssl_engine_kernel.c(1788): OpenSSL: Loop: SSLv3
read server certificate request A
[Thu Oct 16 07:18:41 2003] [debug] ssl_engine_kernel.c(1788): OpenSSL: Loop: SSLv3
read server done A
[Thu Oct 16 07:21:13 2003] [debug] ssl_engine_kernel.c(1554): Proxy client
certificate callback: (host:80) entered
[Thu Oct 16 07:21:55 2003] [debug] ssl_engine_kernel.c(1527): Proxy client
certificate callback: (host:80) found acceptable cert, sending /C=BE/ST=...
[Thu Oct 16 07:31:44 2003] [notice] child pid 2983 exit signal Segmentation fault
(11)
--
ir. Kris Verbeeck
Software Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
Re: Apache won't start - shared memory problem
Graham Leggett wrote: Graham Leggett wrote: My Apache server just went down, and now refuses to come up, logging the following message: [Wed Oct 01 11:16:12 2003] [error] Cannot allocate shared memory: (17)File exists There is no record of which module is emitting this message, nor does the message say which file this is referring to. Anyone know? Turned out to be the file referred to by the SSLSessionCache parameter. Is it also possible to delete this file before Apache starts up, so that this file exists problem cannot occur? That won't solve the problem, the shared memory segment is still registered somewhere in the kernel. I've had lots of problems with this too and only deleting the file does not solve it. You have to remove the segments from the kernel table too (see mail from Paul). -- ir. Kris Verbeeck Software Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Request body validation before content handler phase
Hello, I'm writing an Apache 2.0 module that has to perform some request body validation before actually deciding which content handler to use for response generation. I'm wondering what the best way is to implement this. 1) input filter is a no go, because at the moment the body data passes through the filter, the content handler has already been picked (and is actually pulling that data through the input filters). Right? 2) use the fixup stage, pull all data through the input filters, spool the data while processing (in memory or on disk), remove all input filters from the request structure, insert a new filter that will eventually pass the spooled data to the content handler 3) something else? -- ir. Kris Verbeeck Software Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com smime.p7s Description: S/MIME Cryptographic Signature
Re: Custom SSL verification causes Apache to start using 100% CPU
William A. Rowe, Jr. wrote:
This looks like a bug fixed in the apache 2.1 tree (the current CVS Head
of the httpd-2.0 repository.)
I checked the CVS repository and found the fix you are referring to. Apparently
this was already backported to the 2.0 branch (2.0 diff attached). We patched
the Apache 2.0, but the problem is not fixed. Is this the only patch that is
needed?
The problem also only occurs when use our custom hook. The Apache process
does not hang when using standard CA auth.
We had not reset the BIO information to a blocking read in every possible
path through the filtering code (e.g. a read-back from the client during a
write operation was required to be a blocking read, but the last client read
state may have been blocking. We neglected to reset it.)
This is now fixed in the current code, and checking out the httpd-2.0
repository and building apache's current development tree will help us
to confirm the fix. Thank you for the note.
--
ir. Kris Verbeeck
Software Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.100.2.4
retrieving revision 1.100.2.5
diff -u -r1.100.2.4 -r1.100.2.5
--- httpd-2.0/modules/ssl/ssl_engine_io.c 2003/04/05 19:04:43 1.100.2.4
+++ httpd-2.0/modules/ssl/ssl_engine_io.c 2003/07/28 02:02:24 1.100.2.5
@@ -1275,6 +1275,8 @@
{
apr_status_t status = APR_SUCCESS;
ssl_filter_ctx_t *filter_ctx = f-ctx;
+bio_filter_in_ctx_t *inctx = (bio_filter_in_ctx_t *)
+ (filter_ctx-pbioRead-ptr);
if (f-c-aborted) {
apr_brigade_cleanup(bb);
@@ -1286,6 +1288,13 @@
return ap_pass_brigade(f-next, bb);
}
+/* When we are the writer, we must initialize the inctx
+ * mode so that we block for any required ssl input, because
+ * output filtering is always nonblocking.
+ */
+inctx-mode = AP_MODE_READBYTES;
+inctx-block = APR_BLOCK_READ;
+
if ((status = ssl_io_filter_connect(filter_ctx)) != APR_SUCCESS) {
return ssl_io_filter_error(f, bb, status);
}
@@ -1359,15 +1368,16 @@
filter_ctx-pbioRead = BIO_new(bio_filter_in_method);
filter_ctx-pbioRead-ptr = (void *)inctx;
-inctx-filter_ctx = filter_ctx;
inctx-ssl = ssl;
inctx-bio_out = filter_ctx-pbioWrite;
inctx-f = filter_ctx-pInputFilter;
-inctx-bb = apr_brigade_create(c-pool, c-bucket_alloc);
-
+inctx-rc = APR_SUCCESS;
+inctx-mode = AP_MODE_READBYTES;
inctx-cbuf.length = 0;
-
+inctx-bb = apr_brigade_create(c-pool, c-bucket_alloc);
+inctx-block = APR_BLOCK_READ;
inctx-pool = c-pool;
+inctx-filter_ctx = filter_ctx;
}
void ssl_io_filter_init(conn_rec *c, SSL *ssl)
Custom SSL verification causes Apache to start using 100% CPU
, ssl_callback_SSLVerify);
+}
+}
SSL_set_verify_result(ssl, X509_V_OK);
/* determine whether we've to force a renegotiation */
@@ -729,7 +742,8 @@
* Finally check for acceptable renegotiation results
*/
if (dc-nVerifyClient != SSL_CVERIFY_NONE) {
-BOOL do_verify = (dc-nVerifyClient == SSL_CVERIFY_REQUIRE);
+BOOL do_verify = (dc-nVerifyClient == SSL_CVERIFY_REQUIRE ||
+ dc-nVerifyClient == SSL_CVERIFY_CUSTOM);
if (do_verify (SSL_get_verify_result(ssl) != X509_V_OK)) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,
--
ir. Kris Verbeeck
Software Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
Re: mod_ssl POST issue? (fwd)
Nope, it's still there. Cliff Woolley wrote: Anybody remember if we ever got around to implementing a workaound for the POST method and per-directory renegotiations? --Cliff -- Forwarded message -- Date: Wed, 6 Aug 2003 18:59:05 -0500 From: john lawler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: mod_ssl POST issue? Hi Cliff, I found the below quoted note on a messageboard. This isn't still a bug in mod_ssl is it? I'm encountering similar behavior using a php POST method. Thanks, jl a.. From: Cliff Woolley b.. Subject: Re: POST / SSL / Client Certificates Problem c.. Date: Mon, 08 Apr 2002 12:00:50 -0700 - On Sun, 7 Apr 2002 [EMAIL PROTECTED] wrote: I'm using Apache 2 beta, mod_ssl (obviously), and a few self-signed client certificates. My problem is that when I try to POST to a .cgi file, I get the following error: Method not allowed! The POST method is not allowed for the requested URL. This is a known issue with mod_ssl for Apache 2.0... it's on the modules/ssl/TODO list. Thanks, Cliff -- ir. Kris Verbeeck Software Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
[PATCH] PR 16521 -- caches MUST treat invalid Expires values as inthe past
PR 16521 states that mod_cache caches and returns responses that have an
invalid Expires header (value is 0 or yesterday). The attached patch
resolves this issue.
Some explanation:
- when apr_date_parse_http returns APR_DATE_BAD, the local variable
containing the expires header was reset to NULL;
- the check a bit lower in the code:
if (exps != NULL exp == APR_DATE_BAD) {
would always fail because when exp equals APR_DATE_BAD, exps was always
NULL.
--
Index: modules/experimental/mod_cache.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/experimental/mod_cache.c,v
retrieving revision 1.74
diff -u -r1.74 mod_cache.c
--- modules/experimental/mod_cache.c15 May 2003 17:52:58 - 1.74
+++ modules/experimental/mod_cache.c9 Jun 2003 13:15:48 -
@@ -480,9 +480,7 @@
*/
exps = apr_table_get(r-headers_out, Expires);
if (exps != NULL) {
-if (APR_DATE_BAD == (exp = apr_date_parse_http(exps))) {
-exps = NULL;
-}
+exp = apr_date_parse_http(exps);
}
else {
exp = APR_DATE_BAD;
[PATCH] PR 16520 -- cache MUST NOT cache responses to Authorizationrequests
Actually this PR is not a mod_cache bug. According to RFC 2616,
LWS might be present at the end of an HTTP header.
Quote from RFC 2616:
implied *LWS
The grammar described by this specification is word-based. Except
where noted otherwise, linear white space (LWS) can be included
between any two adjacent words (token or quoted-string), and
between adjacent words and separators, without changing the
interpretation of a field. At least one delimiter (LWS and/or
separators) MUST exist between any two tokens (for the definition
of token below), since they would otherwise be interpreted as a
single token.
So, as PR 16520 states:
Authorization : scheme scheme param=value
is a valid header and should be treated as
Authorization: scheme scheme param=value
Currently Apache does not strip any trailing LWS from the header name.
The attached patch resolves this problem.
--
Index: server/protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/server/protocol.c,v
retrieving revision 1.131
diff -u -r1.131 protocol.c
--- server/protocol.c 15 Apr 2003 22:47:57 - 1.131
+++ server/protocol.c 9 Jun 2003 14:33:42 -
@@ -702,7 +702,7 @@
apr_size_t last_len = 0;
apr_size_t alloc_len = 0;
char *field;
-char *value;
+char *value, *p;
apr_size_t len;
int fields_read = 0;
apr_table_t *tmp_headers;
@@ -790,7 +790,12 @@
return;
}
-*value = '\0';
+p = value - 1;
+while ((last_field p) (*p == ' ' || *p == '\t')) {
+--p;/* Skip to end of name */
+}
+*(p+1) = '\0';
+
++value;
while (*value == ' ' || *value == '\t') {
++value;/* Skip to start of value */
Re: [PATCH] PR 16520 -- cache MUST NOT cache responses to Authorizationrequests
André Malo wrote: So, there's just one token and no place for an implied LWS. [ situation differs from between any two adjacent words (token or quoted-string) ] So, as PR 16520 states: Authorization : scheme scheme param=value is a valid header and should be treated as Authorization: scheme scheme param=value So these are not the same headers, by my reading of the RFC. In fact the former is a Bad Request, since a token cannot contain WS. nd I wasn't 100% sure myself whether the LWS was allowed after the header name... But is reporting a bad request not a bit drastic if removing the LWS can make it compliant? This will make the server more lenient towards malformed header names. But one of the two (stripping LWS or blocking request) should be done because, IMHO, this is a serious security issue. There are back-end servers (in case Apache is used as a proxy) that strip white space from front and end of header names. In that case Apache and the back-end will see different requests (e.g. the Authorization header). --
Re: Now tagged new Apache 2.0.45 candidate.
There is an OpenSSL patch to enable this by default on www.openssl.org. Amund Elstad wrote: Why haven't RSA blinding been enforced in mod_ssl ? It seems the latest releases of mod_ssl for 1.3 does this (ssl_engine_init). amund -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: 28. mars 2003 06:27 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Now tagged new Apache 2.0.45 candidate. Based on observations of broken SSLMutex behavior on Win32, and some other protocol.c based-bugs, we have now created what we hope is the final release candidate tag, WROWE_2_0_45_RC2. See the previous message for detailed instructions. Help is appreciated in testing this tag prior to our rolling the tarball. Once the tarball is tagged, you will also be invited to review the final 2.0.45 candidate before we declare it 'released'. However, bugs at that stage require we start over with 2.0.46, so testing early and often continues to be very helpful. Thanks for your help, Bill -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Re: mod_disk_cache problem
Ori Tend wrote: I'm using apache standard cache configuration (loading mod_disk_cache). Yet for some reason, apache doesn't write anything to the CacheRoot dir. Try enabling debug logging: LogLevel debug The caching modules print a lot of information. Maybe something will show up in the error_log that can help to solve your problem. -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Re: using my module
fabio rohrich wrote: Hi all, I have no a server at home, only a linux station. I'm writing a module that modify the html content. I have the problem that I don't know how to simulate the client server environment. I mean: I can set up a module in a location (with its handler) and I can see how it works (like example-info). but if I want that my module interacts with a file requested from the client, how xan i do it? For example, I can add to my apache the module gzip, but how can I see if it works? Use a packet sniffer and check what is actually being transmitted by client/server. (e.g. www.ethereal.com) I want just to see on my browser the file I request after my module has filtered it. That's the mod_blanks module, right? Can't you just request the file in your browser and then save it (the source) and check whether any blanks were removed? Or are you having trouble enabling the module? Because then it will be a configuration (or programming) issue. -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Re: Module development - Makefile
Esteban Pizzini wrote: I´m trying to develop a simple test module to learn how module works (I´m newly on this), but I have some problems defining Makefile. Is there any reference to do that?? What exactly are you doing in the makefile? It is probably easier to use the 'apxs' script. Just do apxs -c files... -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Re: [PATCH] mod_deflate extensions
Henri Gomez wrote: BTW, I'll next check if mod_deflate works in conjunction with mod_jk/mod_jk2 (where I'm commiter). It works, at least for me. -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Re: low level design
As said before, you will have to use an input filter. Apache does not parse the request body (some modules do, but Apache core does not) and so you will not find any table or somethign in which those form fields are stored. Alistair Young wrote: Hi all, I have a request to the Apache dev people regarding POST data from a client browser. I'm sure that getting data off the wire more than once is out but I ran ngrep while submitting a form to my module and I noticed that the entire page is sent to the server. i.e. the incoming packets contained the HTTP headers (which Apache stores) and the form variables (which it doesn't seem to store) - to get them you need to call ap_should_client_block(), which seems a waste as the data has already come over the wire to Apache with the original request headers. If the form variables are coming in anyway, at the same time as the request headers, does anyone know if Apache stores the form variables in some undocumented table somewhere? If I can get access to the form variables at the header_handler phase then we'll be cooking with gas and the semantic web will come to Apache\PHP\Perl! Cheers, Alistair Alistair Young Senior Applications Specialist Sabhal Mòr Ostaig An Teanga Slèite An t-Eilean Sgitheanach Alba IV44 8RQ UK Fòn:01471 888343 Post-dealanach: [EMAIL PROTECTED] [EMAIL PROTECTED] 10/29/02 15:15 PM Alistair Young [EMAIL PROTECTED] writes: Hi all, I've just joined the list so please forgive me if this is the wrong area for this. I would like to find out if it's possible to call ap_should_client_block / ap_get_client_block more than once between modules. I'm working on mod_sw (semantic web) and need to access form data in the body of the request but also leave it intact for other modules (PHP etc.) to use. ap_get_client_block() consumes the data. If your module needs to see the data that would be consumed by some other module, you can use an input filter (Apache 2.0). -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien... -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
[PATCH] htpasswd
Solves the following issue from the STATUS file:
* htpasswd blindly processes the file you give it, and does no
sanity checking before totally corrupting whatever file it was
you thought you had. It should check the input file and bail
if it finds non-comment lines that do not contain exactly 1
':' character.
Message-ID: [EMAIL PROTECTED]
htpasswd will return error code 7 if the file contains invalid entries.
The patch contains a diff for htpasswd.c, htpasswd.1 (the man page) and
htpasswd.html (the HTML manual). I think that's it.
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
--- docs/man/htpasswd.1 13 Mar 2002 20:47:40 - 1.7
+++ docs/man/htpasswd.1 22 Oct 2002 09:39:43 -
@@ -197,8 +197,9 @@
was a syntax problem with the command line, 3 if the password was
entered interactively and the verification entry didn't match, 4 if
its operation was interrupted, 5 if a value is too long (username,
-filename, password, or final computed record), and 6 if the username
-contains illegal characters (see the \fBRESTRICTIONS\fP section).
+filename, password, or final computed record), 6 if the username
+contains illegal characters (see the \fBRESTRICTIONS\fP section),
+and 7 if the \fIpasswdfile\fP contains invalid entries.
.SH EXAMPLES
\fBhtpasswd /usr/local/etc/apache/.htpasswd-users jsmith\fP
.IP
--- docs/manual/programs/htpasswd.html 22 Sep 2001 19:38:35 - 1.3
+++ docs/manual/programs/htpasswd.html 22 Oct 2002 09:39:44 -
@@ -110,9 +110,10 @@
the command line, 3 if the password was entered interac-
tively and the verification entry didn't match, 4 if its
operation was interrupted, 5 if a value is too long (user-
- name, filename, password, or final computed record), and 6
+ name, filename, password, or final computed record), 6
if the username contains illegal characters (see the strongRES-/strong
- strongTRICTIONS/strong section).
+ strongTRICTIONS/strong section), and 7 if the empasswdfile/em
+ contains invalid entries.
strongEXAMPLES/strong
stronghtpasswd /usr/local/etc/apache/.htpasswd-users jsmith/strong
--- support/htpasswd.c 8 Oct 2002 11:21:25 - 1.67
+++ support/htpasswd.c 22 Oct 2002 09:39:46 -
@@ -77,6 +77,7 @@
* 5: Failure; buffer would overflow (username, filename, or computed
* record too long)
* 6: Failure; username contains illegal or reserved characters
+ * 7: Failure; file is invalid
*/
#include apr.h
@@ -133,6 +134,7 @@
#define ERR_INTERRUPTED 4
#define ERR_OVERFLOW 5
#define ERR_BADUSER 6
+#define ERR_BADFILE 7
#define APHTP_NEWFILE1
#define APHTP_NOFILE 2
@@ -577,6 +579,10 @@
colon = strchr(scratch, ':');
if (colon != NULL) {
*colon = '\0';
+} else {
+ apr_file_close(fpw);
+ apr_file_close(ftemp);
+ exit(ERR_BADFILE);
}
if (strcmp(user, scratch) != 0) {
putline(ftemp, line);
Re: [PATCH] htpasswd
André Malo wrote: * Kris Verbeeck wrote: * htpasswd blindly processes the file you give it, and does no sanity checking before totally corrupting whatever file it was you thought you had. It should check the input file and bail if it finds non-comment lines that do not contain exactly 1 ':' character. Message-ID: [EMAIL PROTECTED] Sorry, if I'm too late, but this is a bad criterion, since the parser of mod_auth/mod_authn_file uses the second colon as a delimiter and many people put comments after it. The second colon is also /neccessary/ if you want plain text passwords (e.g. under win32) that end with spaces... [Yes, I've seen this already] The current patch only bails out if there is no colon, so two colons should not be a problem. -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
[PATCH] [UPDATED] Re: Cached response: 304 send as 200
Brian Pane wrote:
If the read of this field is removed, won't we also need to remove
the code that writes it?
Correct, my mistake... new patch has been attached that also removes
the writing of the status line.
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
--- mod_disk_cache.cFri Sep 13 09:44:09 2002
+++ mod_disk_cache.c-PATCHEDFri Sep 13 09:52:44 2002
-484,17 +484,6
r-status = atoi(urlbuff); /* Save status line into
request rec */
-rv = apr_file_gets(urlbuff[0], urllen, dobj-hfd); /* Read status
line */
-if (rv != APR_SUCCESS) {
-/* XXX log message */
- return rv;
-}
-
-if ((temp = strchr(urlbuff[0], '\n')) != NULL) /* trim off new line
character */
- *temp = '\0'; /* overlay it with the null terminator */
-
-r-status_line = apr_pstrdup(r-pool, urlbuff);/* Save status line
into request rec */
-
h-req_hdrs = apr_table_make(r-pool, 20);
/*
-592,17 +581,6
}
sprintf(statusbuf,%d, r-status);
buf = apr_pstrcat(r-pool, statusbuf, CRLF, NULL);
-amt = strlen(buf);
-apr_file_write(hfd, buf, amt);
-
-/* This case only occurs when the content is generated locally */
-if (!r-status_line) {
-r-status_line = ap_get_status_line(r-status);
-}
-buf = apr_pstrcat(r-pool, r-status_line, \n, NULL);
-amt = strlen(buf);
-apr_file_write(hfd, buf, amt);
-buf = apr_pstrcat(r-pool, CRLF, NULL);
amt = strlen(buf);
apr_file_write(hfd, buf, amt);
Re: [PATCH] caching and query strings
Ian Holsman wrote: On Thu, 12 Sep 2002 03:47:58 -0700, Paul J. Reder wrote: Yes, I believe it should check r-args. I don't think you are stupid, severely or otherwise... ;) it should not make a difference really if r-args is null than the strcat should terminate there anyway ;-) that's what I thought :-) -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Re: Cached response: 304 send as 200
Graham Leggett wrote: The response: HTTP/1.0 200 Date: Tue, 10 Sep 2002 09:45:39 GMT Server: web server Connection: close etag: b9829-2269-3cd12aa1 Another bug - why is an HTTP/1.1 response prefixed with HTTP/1.0...? Nope, there is a force-response-1.0 in httpd.conf for this request. So normal behaviour. -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
[PATCH] Re: Cached response: 304 send as 200
Hi,
Attached is a patch that will solve the 304 turning into 200 response code
problem. It seems that in mod_disk_cache the status line was also saved
and restored from the cache. On a first request it is saved as 200 OK or
something to the cache file. On subsequent requests it is restored into
r-status_line.
The problem occurs when afterwards mod_cache decides that the response
should be a 304 not modified. The status line is not reset in this case
and send as a 200 OK response without a body.
The solution: not restoring the status line from the cache. The http
response header filter will then construct a status line starting from
the status code, which is 304. Problem solved.
Kris Verbeeck wrote:
Hi,
When refreshing a page (with IE) the browser sends a 'If-Modified-Since'
header in the request. As seen in the debug log below, mod_cache has
verified that the page has not been modified and wants to return an HTTP
status 304. Somehow this 304 doesn't get to the browser. Instead of
sending the 304 response apache sends a 200 response without a body
(see ethereal output of request and response below). This results in the
browser displaying an empty (white) page.
If a request is send without the 'If-Modified-Since' header then everything
works OK, i.e. a 200 response is send with the cached body.
I have already been tracing through httpd with gdb, but found nothing.
Does anyone have any idea about what is going on with the 304 response?
Setup: apache httpd 2.0.40 (with cache patches from CVS)
The request:
GET /index.html HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 02 May 2002 12:01:37 GMT; length=8809
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Host: pino.be.ubizen.com
Connection: Keep-Alive
The response:
HTTP/1.0 200
Date: Tue, 10 Sep 2002 09:45:39 GMT
Server: web server
Connection: close
etag: b9829-2269-3cd12aa1
The debug log:
[date] [debug] mod_cache.c(112): cache: URL /index.html is being handled by
disk
[date] [info] disk_cache: Serving Cached URL /index.html
[date] [info] disk_cache: Served headers for URL /index.html
[date] [debug] mod_cache.c(216): cache: fresh cache - returning status 304
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
--- mod_disk_cache.cWed Sep 11 16:33:25 2002
+++ mod_disk_cache.c-PATCHEDWed Sep 11 16:32:54 2002
-484,6 +484,17
r-status = atoi(urlbuff); /* Save status line into
request rec */
+rv = apr_file_gets(urlbuff[0], urllen, dobj-hfd); /* Read status
+line */
+if (rv != APR_SUCCESS) {
+/* XXX log message */
+ return rv;
+}
+
+if ((temp = strchr(urlbuff[0], '\n')) != NULL) /* trim off new line
+character */
+ *temp = '\0'; /* overlay it with the null terminator */
+
+r-status_line = apr_pstrdup(r-pool, urlbuff);/* Save status line
+into request rec */
+
h-req_hdrs = apr_table_make(r-pool, 20);
/*
Cached response: 304 send as 200
Hi, When refreshing a page (with IE) the browser sends a 'If-Modified-Since' header in the request. As seen in the debug log below, mod_cache has verified that the page has not been modified and wants to return an HTTP status 304. Somehow this 304 doesn't get to the browser. Instead of sending the 304 response apache sends a 200 response without a body (see ethereal output of request and response below). This results in the browser displaying an empty (white) page. If a request is send without the 'If-Modified-Since' header then everything works OK, i.e. a 200 response is send with the cached body. I have already been tracing through httpd with gdb, but found nothing. Does anyone have any idea about what is going on with the 304 response? Setup: apache httpd 2.0.40 (with cache patches from CVS) The request: GET /index.html HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate If-Modified-Since: Thu, 02 May 2002 12:01:37 GMT; length=8809 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Host: pino.be.ubizen.com Connection: Keep-Alive The response: HTTP/1.0 200 Date: Tue, 10 Sep 2002 09:45:39 GMT Server: web server Connection: close etag: b9829-2269-3cd12aa1 The debug log: [date] [debug] mod_cache.c(112): cache: URL /index.html is being handled by disk [date] [info] disk_cache: Serving Cached URL /index.html [date] [info] disk_cache: Served headers for URL /index.html [date] [debug] mod_cache.c(216): cache: fresh cache - returning status 304 -- ir. Kris Verbeeck Development Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
mod_deflate in 2.0.40
Hi,
The 2.0.39 code:
if ((r-content_type == NULL || strncmp(r-content_type, text/html, 9))
apr_table_get(r-subprocess_env, gzip-only-text/html)) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
says 'if we have a response with a content-type other than text/html AND
the environment variable gzip-only-text/html is defined then we will
not deflate (remove filter)'
The 2.0.40 code:
if (r-content_type == NULL || strncmp(r-content_type, text/html, 9)) {
const char *env_value = apr_table_get(r-subprocess_env, gzip-only-text/html);
if ( env_value == NULL || strcmp(env_value,1) ) {
ap_remove_output_filter(f);
}
return ap_pass_brigade(f-next, bb);
}
says 'if we have a response with a content-type other than text/html AND
gzip-only-text/html is not defined OR it is defined but different from 1
then we will not deflate (remove filter)'
IMHO this is something completely different. With the new code the filter is always
removed unless you define gzip-only-text/html to be 1. So you can't compress
other files, e.g. .txt. I think the strcmp test should be strcmp(...) == 0.
Or am I missing something??
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
[PATCH] Re: mod_deflate in 2.0.40
Hi again,
After testing I discovered that some more changes were needed to get it to work.
Patch has been attached. This patch should still have the behaviour of enabling
compression when gzip-only-text/html is set to something other than 1. It
will also enable compression if gzip-only-text/html is not set at all.
Kris Verbeeck wrote:
Hi,
The 2.0.39 code:
if ((r-content_type == NULL || strncmp(r-content_type, text/html, 9))
apr_table_get(r-subprocess_env, gzip-only-text/html)) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
says 'if we have a response with a content-type other than text/html AND
the environment variable gzip-only-text/html is defined then we will
not deflate (remove filter)'
The 2.0.40 code:
if (r-content_type == NULL || strncmp(r-content_type, text/html, 9)) {
const char *env_value = apr_table_get(r-subprocess_env, );
if ( env_value == NULL || strcmp(env_value,1) ) {
ap_remove_output_filter(f);
}
return ap_pass_brigade(f-next, bb);
}
says 'if we have a response with a content-type other than text/html AND
gzip-only-text/html is not defined OR it is defined but different from 1
then we will not deflate (remove filter)'
IMHO this is something completely different. With the new code the filter is always
removed unless you define gzip-only-text/html to be 1. So you can't compress
other files, e.g. .txt. I think the strcmp test should be strcmp(...) == 0.
Or am I missing something??
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
--- httpd-2.0.40/modules/filters/mod_deflate.c Wed Aug 7 17:26:17 2002
+++ httpd-2.0.40-PATCHED/modules/filters/mod_deflate.c Fri Aug 30 13:15:22 2002
-281,10 +281,10
|| strncmp(r-content_type, text/html, 9)) {
const char *env_value = apr_table_get(r-subprocess_env,
gzip-only-text/html);
-if ( env_value == NULL || strcmp(env_value,1) ) {
+if ( (env_value != NULL) (strcmp(env_value,1) == 0) ) {
ap_remove_output_filter(f);
+return ap_pass_brigade(f-next, bb);
}
-return ap_pass_brigade(f-next, bb);
}
/* Let's see what our current Content-Encoding is.
Re: [PATCH] fixes segfault in mod_cache (2.0.40)
Apache behaviour with this patch (or without mod_cache):
The request:
GET https://whatever.html HTTP/1.0
is equivalent to:
GET / HTTP/1.0
I'm wondering whether this is the desired behaviour? This is
also the behaviour of a 1.3.x Apache. Maybe Apache should block
this kind of requests and return an error message??
Kris Verbeeck wrote:
Hi,
Someone in our QA team tried the following test:
telnet host 80
GET https://whatever.html HTTP/1.0
this resulted in a segfault for the child that handled the request.
Agreed, this is not a normal HTTP request, but firing enough of them
will surely DoS the server.
Our apache runs on Sparc/Solaris8 and 'httpd -l' gives:
Compiled in modules:
core.c
mod_access.c
mod_cache.c
mod_disk_cache.c
mod_deflate.c
mod_jk.c
mod_log_config.c
mod_env.c
mod_setenvif.c
mod_ssl.c
prefork.c
http_core.c
mod_mime.c
mod_alias.c
Gdb told me that there was a null ppinter dereference in
ap_cache_get_cache_type when it tried to compare the request's
URL with the prefix from the configuration.
The patch will just return NULL when the URL is NULL and results
in no caching for that request (which seems reasonable since there
ios no URL to cache).
ps: I don't know whether the actual fix of this problem should
be in cache_util.c or somewhere in the URI parsing routines.
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
--- httpd-2.0.40/modules/experimental/cache_util.c Sun Jun 23 08:10:00 2002
+++ httpd-2.0.40-PATCHED/modules/experimental/cache_util.c Mon Aug 26 17:28:37
2002
-104,6 +104,12
const char *type = NULL;
int i;
+/* we can't cache if there's no URL
+ * fixes segfault for 'GET https://whatever.html HTTP/1.0' request
+ * on HTTP port (e.g. 80)
+ */
+if (!url) return NULL;
+
/* loop through all the cacheenable entries */
for (i = 0; i conf-cacheenable-nelts; i++) {
struct cache_enable *ent =
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
