Re: svn commit: r1893327 - /httpd/dev-tools/github/apply_trunk_pr.sh

[Rüdiger Plüm]

On 9/14/21 1:26 PM, Eric Covener wrote:
> On Tue, Sep 14, 2021 at 2:57 AM  wrote:
>>
>> Author: rpluem
>> Date: Tue Sep 14 06:57:34 2021
>> New Revision: 1893327
>>
>> URL: http://svn.apache.org/viewvc?rev=1893327=rev
>> Log:
>> * Add commit authors to clog as Submitted by
>>
>> Modified:
>> httpd/dev-tools/github/apply_trunk_pr.sh
>>
>> Modified: httpd/dev-tools/github/apply_trunk_pr.sh
>> URL: 
>> http://svn.apache.org/viewvc/httpd/dev-tools/github/apply_trunk_pr.sh?rev=1893327=1893326=1893327=diff
>> ==
>> --- httpd/dev-tools/github/apply_trunk_pr.sh (original)
>> +++ httpd/dev-tools/github/apply_trunk_pr.sh Tue Sep 14 06:57:34 2021
>> @@ -34,5 +34,9 @@ fi
>>  curl -s https://api.github.com/repos/apache/httpd/pulls/${PR}/commits | jq 
>> .[].commit.message | perl -pe 's/^"//; s/"$//; s/\\n/\n/g; ' > clog
>>
>>  echo >> clog
>> +AUTHORS=`curl -s 
>> https://api.github.com/repos/apache/httpd/pulls/266/commits | jq 
>> '.[].commit.author|.name,.email' | perl -e 'while (<>) { s/^"//; s/"$//; 
>> chomp $_; if (defined($a)) { $b{"$a <$_>\n"} = 1; $a = undef; } else { $a = 
>> $_; }} print join(",", map { chomp $_; $_ } sort, keys(%b)); '`
>> +echo "Submitted by: $AUTHORS" >> clog
>> +
>
> s/266/${PR}/ ?

Rats! Thanks for catching. r1893334.

Regards

Rüdiger

Re: APLOGNO number range for vendors?

[Rüdiger Plüm]

On 12/1/20 4:02 PM, Yehuda Katz wrote:
> Would a crazy option 4 be to add VENDOR_APLOGNO() which could add a prefix to 
> the log number to be used in any patches?
>
> For example, V_APLOGNO('R', 123) could produce AHR123
>
> This would make it clear that the error comes from a patch from another 
> distribution.

Sounds like a good idea, as this would allow each vendor to manage its own 
number range independently from each other and us
and it would be easy to spot such vendor specific error numbers in any kind of 
reports.

Regards

Rüdiger

Re: svn commit: r1882776 - /httpd/httpd/trunk/.travis.yml

[Rüdiger Plüm]

On 10/29/20 3:51 PM, Joe Orton wrote:
> On Fri, Oct 23, 2020 at 10:07:39AM +0200, Ruediger Pluem wrote:
>>
>>
>> On 10/23/20 8:24 AM, rpl...@apache.org wrote:
>>> Author: rpluem
>>> Date: Fri Oct 23 06:24:55 2020
>>> New Revision: 1882776
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1882776=rev
>>> Log:
>>> * Two first tests using Ubuntu Focal
>>>
>>> Modified:
>>> httpd/httpd/trunk/.travis.yml
>>>
>>> Modified: httpd/httpd/trunk/.travis.yml
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/.travis.yml?rev=1882776=1882775=1882776=diff
>>> ==
>>> --- httpd/httpd/trunk/.travis.yml (original)
>>> +++ httpd/httpd/trunk/.travis.yml Fri Oct 23 06:24:55 2020
>>> @@ -214,6 +214,18 @@ jobs:
>>> CONFIG="--enable-mods-shared=reallyall"
>>> APU_CONFIG="--with-crypto --with-ldap"
>>>  # 
>>> -
>>> +- if: *condition_24x_only
>>> +  name: Linux Ubuntu Focal, all-modules, system APR/APR-util
>>> +  os: linux
>>> +  dist: focal
>>> +  env: CONFIG="--enable-mods-shared=reallyall"
>>> +# 
>>> -
>>> +- name: Linux Ubuntu Focal, all-modules, APR 1.7.0, APR-util 1.6.1
>>> +  dist: focal
>>> +  env: APR_VERSION=1.7.0 APU_VERSION=1.6.1
>>> +   CONFIG="--enable-mods-shared=reallyall"
>>> +   APU_CONFIG="--with-crypto --with-ldap"
>>> +# 
>>> -
>>>  - name: Linux Ubuntu, APR 1.7.0, APR-util 1.6.1
>>>env: APR_VERSION=1.7.0 APU_VERSION=1.6.1
>>> CONFIG="--enable-mods-shared=reallyall"
>>>
>>
>> As Ubuntu Focal seems to work 
>> (https://travis-ci.org/github/apache/httpd/builds/738225395)
>
> Thanks for adding it!
>
>> I ask myself what we should do now with regards to testing. Should we
>>
>> 1. Clone all Bionic tests and run them with Focal as well?
>> 2. Switch the Bionic tests to Focal?
>> 3. Do a mixture of 1. and 2.: Switch some Bionic tests to Focal and clone 
>> the ones we leave on Bionic to Focal?
>
> I think it would be fine just running a couple of all-modules tests on
> Focal, with built-APR and system-APR just as you've done it.
>
> Also the *condition_24x_only should be unnecessary for Focal which has
> APR 1.6 (sufficient for trunk).  It's necessary for Xenial because that
> has a too-old APR to build trunk against.

Condition removed in

Regards

Rüdiger

Re: svn commit: r1869338 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/ap_mmn.h modules/proxy/mod_proxy.h modules/proxy/mod_proxy_connect.c modules/proxy/mod_proxy_wstunne

[Rüdiger Plüm]

On 11/04/2019 10:55 PM, Yann Ylavic wrote:
> On Mon, Nov 4, 2019 at 10:16 PM Ruediger Pluem  wrote:
>>
>>
>>
>> On 11/04/2019 06:12 PM, Yann Ylavic wrote:
>>> On Mon, Nov 4, 2019 at 4:16 PM Ruediger Pluem  wrote:


>>
>> Just that I get it correct:
>>
>> This would require something like
>>
>> ProxyPass / ws://hostname/
>> ProxyPass / http://hostname/
>>
>> to work and would only work with ProxyPass,
>
> Yes, that's the idea. I think the ProxyPass(es) order matters here
> though, because proxy_trans() walks the aliases in configuration
> order, so if it finds "http" first then "ws" will never be elected.

Exactly order is important here.

>
> We could be more clever, not sure it's worth it...
> My plan is to handle the "ws(s)" schemes in mod_proxy_http directly,
> using the new proxy tunnel interface of this commit to start tunneling
> if/when needed (according to the backend). Then mod_proxy_wstunnel
> would be obsolete.

Could make it easier, but not sure if it's worth it.

>
>> not with RewriteRules and [P] flag, correct?
>
> mod_rewrite wouldn't be concerned indeed, but today one can already:
>
>   RewriteCond %{HTTP:Upgrade} websocket [NC]
>   RewriteRule / ws://hostname/ [P]
>
> to make this work.

In parallel to

RewriteRule ^/(.*) http://hostname/$1 [P]

Good point. In this case order only matters from performance point of view in 
order to limit the amount of RewriteRules
executed for the common case.

Regards

Rüdiger

Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)

[Rüdiger Plüm]

On 10/28/2019 10:54 AM, Yann Ylavic wrote:
> On Mon, Oct 28, 2019 at 9:24 AM Stefan Eissing
>  wrote:
>>
>> Ok, let me summarize:
>>
>> - SSLProtocol on base server applies, unless vhost has its own setting
>> - no SSLProtocol on base server, SSLProtocol on vhost applies
>> - no SSLProtocol on base server, no SSLProtocol on vhost, possible 
>> SSLProtocol on base vhost applies
>
> That's it, I'd call "base server" the "global server", though, to
> avoid confusion w.r.t. to c->base_server (the "base vhost" in the
> above).
>
> For 2.4.x, this means that there is a behavioural change when:
> - SSLProtocol is specified in a non-base vhost (but this is the point),
> - no SSLProtocol is specified in a non-base vhost AND one is specified
> globally (here the global applies, whereas previously the base vhost's
> applied).
>
> Once/if backported, I plan to completely remove the base vhost from
> the game, in trunk (usual merging applies).

So you want to revert r1868929 after the backport?

As far as I can tell r1868929 keeps the inheritance behavior closer to the
previous 2.4.x and trunk behavior, but is different compared to the
inheritance behavior of already SNI respecting directives like e.g. 
SSLCipherSuite.
Removing r1868929 would bring both (the directives respecting SNI so far
and the ones that NOW respect SNI) to the same inheritance level, correct?

Regards

Rüdiger

Re: svn commit: r1863191 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/generators/cgi_common.h modules/generators/mod_cgi.c modules/generators/mod_cgid.c

[Rüdiger Plüm]

On 07/17/2019 09:51 AM, jor...@apache.org wrote:
> Author: jorton
> Date: Wed Jul 17 07:51:53 2019
> New Revision: 1863191
>
> URL: http://svn.apache.org/viewvc?rev=1863191=rev
> Log:
> mod_cgid: Continuation of r1862968, experimental fd passing support.
>
> Split out CGI bucket implementation from mod_cgi and use in both
> mod_cgi and mod_cgid, bringing stderr handling in mod_cgid up to par
> with mod_cgi.  (There is a lot of code which has been copied between
> mod_cgi{,d} so there's scope for further reduction of source
> duplication between the modules using this header)
>
> * modules/generators/cgi_common.h: Copied from mod_cgi.c, removed
>   everything but the CGI bucket implementation with only one change:
>   (struct cgi_bucket_data, cgi_bucket_create, cgi_bucket_read): Take a
>   timeout on bucket creation, store and use on reads.
>
> * modules/generators/mod_cgi.c [APR_FILES_AS_SOCKETS]: Include
>   cgi_common.h.
>   (cgi_handler): Pass configured timeout to CGI bucket.
>
> * modules/generators/mod_cgid.c: Include cgi_common.h.
>   (log_script_err): Copy from mod_cgi.c.
>   (log_script): Use log_script_err.
>   (send_req): Take fd for stderr.
>   (cgid_child_errfn): Handle fd-passing case by writing error
>   to stderr for client to pass through ap_log_rerror.
>   (cgid_handler): Create pipe for stderr, pass write-end to
>   server via send_req, use read-end to create CGI bucket.  Handle
>   stderr output in failure paths.
>
> PR: 54221
>
> Added:
> httpd/httpd/trunk/modules/generators/cgi_common.h
>   - copied, changed from r1863117, 
> httpd/httpd/trunk/modules/generators/mod_cgi.c
> Modified:
> httpd/httpd/trunk/docs/log-message-tags/next-number
> httpd/httpd/trunk/modules/generators/mod_cgi.c
> httpd/httpd/trunk/modules/generators/mod_cgid.c
>
>
> Copied: httpd/httpd/trunk/modules/generators/cgi_common.h (from r1863117, 
> httpd/httpd/trunk/modules/generators/mod_cgi.c)
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/cgi_common.h?p2=httpd/httpd/trunk/modules/generators/cgi_common.h=httpd/httpd/trunk/modules/generators/mod_cgi.c=1863117=1863191=1863191=diff
> ==
> --- httpd/httpd/trunk/modules/generators/mod_cgi.c (original)
> +++ httpd/httpd/trunk/modules/generators/cgi_common.h Wed Jul 17 07:51:53 2019

> @@ -598,11 +34,13 @@ static const apr_bucket_type_t bucket_ty
>  struct cgi_bucket_data {
>  apr_pollset_t *pollset;
>  request_rec *r;
> +apr_interval_time_t timeout;
>  };
>
>  /* Create a CGI bucket using pipes from script stdout 'out'
>   * and stderr 'err', for request 'r'. */
>  static apr_bucket *cgi_bucket_create(request_rec *r,
> + apr_interval_time_t timeout,
>   apr_file_t *out, apr_file_t *err,
>   apr_bucket_alloc_t *list)
>  {
> @@ -648,6 +86,7 @@ static apr_bucket *cgi_bucket_create(req
>  }
>
>  data->r = r;
> +data->timeout = timeout;
>  b->data = data;
>  return b;
>  }
> @@ -714,10 +153,9 @@ static apr_status_t cgi_bucket_read(apr_
>  apr_interval_time_t timeout = 0;
>  apr_status_t rv;
>  int gotdata = 0;
> -cgi_dirconf *dc = ap_get_module_config(data->r->per_dir_config, 
> _module);
>
>  if (block != APR_NONBLOCK_READ) {
> -timeout = dc->timeout > 0 ? dc->timeout : data->r->server->timeout;
> +timeout = data->timeout > 0 ? data->timeout : 
> data->r->server->timeout;
>  }
>
>  do {

Shouldn't that code go into something like cgi_util.c which is linked to both 
modules leaving only the structure and
prototype stuff in the header file? Or is this too much of a hassle since it 
creates some sort of CGI-API as the symbols
in cgi_util.c cannot be static but need to be exported?

Regards

Rüdiger

Re: svn commit: r1753223 - /httpd/httpd/trunk/modules/http/http_protocol.c

[Rüdiger Plüm]

On 07/18/2016 05:28 PM, William A Rowe Jr wrote:
> On Mon, Jul 18, 2016 at 10:22 AM, Ruediger Pluem  > wrote:
> 
> 
> On 07/18/2016 03:41 PM, wr...@apache.org  wrote:
> > Author: wrowe
> > Date: Mon Jul 18 13:41:26 2016
> > New Revision: 1753223
> >
> > URL: http://svn.apache.org/viewvc?rev=1753223=rev
> > Log:
> > Simplify; this code is executed one per request processed, saving
> > an immeasurably small quantum of CPU of a server under load.
> >
> > +int *methnum = apr_hash_get(methods_registry, method, len);
> 
> How do we ensure that methods_registry is not NULL or better that
> ap_method_registry_init was called before?
> 
>  
> Is the ap_method_registry_init in mod_http register_hooks() insufficient?
> 
> 
> 

Doh. I missed that. Sorry for the noise.

Regards

Rüdiger

Re: svn commit: r1737382 - /httpd/httpd/trunk/docs/manual/mod/core.xml

[Rüdiger Plüm]

On 04/01/2016 03:48 PM, Eric Covener wrote:
> I am -0.9 on this info in the manual, for a relatively low severity bug.

+1. We don't do this kind of stuff in the documentation. This is what CHANGES 
and Bugzilla are for.

Regards

Rüdiger



> 
> On Fri, Apr 1, 2016 at 9:31 AM,   wrote:
>> Author: elukey
>> Date: Fri Apr  1 13:31:28 2016
>> New Revision: 1737382
>>
>> URL: http://svn.apache.org/viewvc?rev=1737382=rev
>> Log:
>> Added warning for AllowOverrideList None in the mod-core doc (PR 58528)
>>
>> Modified:
>> httpd/httpd/trunk/docs/manual/mod/core.xml
>>
>> Modified: httpd/httpd/trunk/docs/manual/mod/core.xml
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/core.xml?rev=1737382=1737381=1737382=diff
>> ==
>> --- httpd/httpd/trunk/docs/manual/mod/core.xml (original)
>> +++ httpd/httpd/trunk/docs/manual/mod/core.xml Fri Apr  1 13:31:28 2016
>> @@ -328,6 +328,14 @@ NoDecode option available in 2.3.12 and
>>  completely ignored. In this case, the server will not even attempt
>>  to read .htaccess files in the filesystem.
>>
>> +AllowOverrideList bug in versions = 2.4.18
>> +AllowOverrideList will not 
>> prevent
>> +.htaccess files processing when explicitly set with None in httpd 
>> versions = 2.4.18 due to a
>> +https://bz.apache.org/bugzilla/show_bug.cgi?id=58528;>bug.
>> +Set only AllowOverride to None as 
>> workaround if
>> +you are unable to upgrade to httpd  2.4.18
>> +
>> +
>>  When this directive is set to All, then any
>>  directive which has the .htaccess >  href="directive-dict.html#Context">Context is allowed in
>> @@ -520,6 +528,14 @@ AllowOverride AuthConfig Indexes
>>  ignored.  In this case, the server will not even attempt to read
>>  .htaccess files in the filesystem.
>>
>> +AllowOverrideList bug in versions = 2.4.18
>> +AllowOverrideList will not 
>> prevent
>> +.htaccess files processing when explicitly set with None in httpd 
>> versions = 2.4.18 due to a
>> +https://bz.apache.org/bugzilla/show_bug.cgi?id=58528;>bug.
>> +Set only AllowOverride to None as 
>> workaround if
>> +you are unable to upgrade to httpd  2.4.18
>> +
>> +
>>  Example:
>>
>>  
>>
>>
> 
> 
> 

Fwd: svn commit: r1445100 - in /httpd/httpd/branches/2.2.x: ./ CHANGES STATUS server/mpm_common.c

[Rüdiger Plüm]

 Original Message 
Subject:svn commit: r1445100 - in /httpd/httpd/branches/2.2.x: ./ 
CHANGES STATUS server/mpm_common.c
Date:   Tue, 12 Feb 2013 10:54:42 GMT
From:   rj...@apache.org



Author: rjung
Date: Tue Feb 12 10:54:42 2013
New Revision: 1445100

URL: http://svn.apache.org/r1445100
Log:
server/mpm_unix.c (dummy_connection): Use a TLS 1.0 close_notify
alert if the chosen listener is configured for https; not perfect
but better than sending an HTTP request.  Adjust comments.

Backport of r1327036 and r1327080 from turnk,
resp. r1356884 from 2.4.x.

Submitted by: jorton
Reviewed by: covener, wrowe
Backported by: rjung

Modified:
 httpd/httpd/branches/2.2.x/   (props changed)
 httpd/httpd/branches/2.2.x/CHANGES
 httpd/httpd/branches/2.2.x/STATUS
 httpd/httpd/branches/2.2.x/server/mpm_common.c


Modified: httpd/httpd/branches/2.2.x/server/mpm_common.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/server/mpm_common.c?rev=1445100r1=1445099r2=1445100view=diff
==
--- httpd/httpd/branches/2.2.x/server/mpm_common.c (original)
+++ httpd/httpd/branches/2.2.x/server/mpm_common.c Tue Feb 12 10:54:42 2013
@@ -636,14 +636,14 @@ static apr_status_t pod_signal_internal(
  return rv;
  }

-/* This function connects to the server, then immediately closes the 
connection.
- * This permits the MPM to skip the poll when there is only one listening
- * socket, because it provides a alternate way to unblock an accept() when
- * the pod is used.
- */
+/* This function connects to the server and sends enough data to
+ * ensure the child wakes up and processes a new connection.  This
+ * permits the MPM to skip the poll when there is only one listening
+ * socket, because it provides a alternate way to unblock an accept()
+ * when the pod is used.  */
  static apr_status_t dummy_connection(ap_pod_t *pod)
  {
-char *srequest;
+const char *data;
  apr_status_t rv;
  apr_socket_t *sock;
  apr_pool_t *p;
@@ -697,24 +697,38 @@ static apr_status_t dummy_connection(ap_
  return rv;
  }

-/* Create the request string. We include a User-Agent so that
- * adminstrators can track down the cause of the odd-looking
- * requests in their logs.
- */
-srequest = apr_pstrcat(p, OPTIONS * HTTP/1.0\r\nUser-Agent: ,
+if (lp-protocol  strcasecmp(lp-protocol, https) == 0) {
+/* Send a TLS 1.0 close_notify alert.  This is perhaps the
+ * least wrong way to open and cleanly terminate an SSL
+ * connection.  It should work without noisy error logs if
+ * the server actually expects SSLv3/TLSv1.  With
+ * SSLv23_server_method() OpenSSL's SSL_accept() fails
+ * ungracefully on receipt of this message, since it requires
+ * an 11-byte ClientHello message and this is too short. */
+static const unsigned char tls10_close_notify[7] = {
+'\x15', /* TLSPlainText.type = Alert (21) */
+'\x03', '\x01', /* TLSPlainText.version = {3, 1} */
+'\x00', '\x02', /* TLSPlainText.length = 2 */
+'\x01', /* Alert.level = warning (1) */
+'\x00'  /* Alert.description = close_notify (0) */
+};
+data = (const char *)tls10_close_notify;
+len = sizeof(tls10_close_notify);
+}
+else /* ... XXX other request types here? */ {
+/* Create an HTTP request string.  We include a User-Agent so
+ * that adminstrators can track down the cause of the
+ * odd-looking requests in their logs.  A complete request is
+ * used since kernel-level filtering may require that much
+ * data before returning from accept(). */
+data = apr_pstrcat(p, OPTIONS * HTTP/1.0\r\nUser-Agent: ,
 ap_get_server_banner(),
  (internal dummy connection)\r\n\r\n, NULL);
+len = strlen(data);
+}

-/* Since some operating systems support buffering of data or entire
- * requests in the kernel, we send a simple request, to make sure
- * the server pops out of a blocking accept().
- */
-/* XXX: This is HTTP specific. We should look at the Protocol for each
- * listener, and send the correct type of request to trigger any Accept
- * Filters.
- */
  len = strlen(srequest);

Don't we need to remove this line as well? srequest is now data.

-apr_socket_send(sock, srequest,len);
+apr_socket_send(sock, data,len);
  apr_socket_close(sock);
  apr_pool_destroy(p);

Fwd: svn commit: r1386726 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/slotmem/mod_slotmem_shm.c

[Rüdiger Plüm]

 Original Message 
Subject:svn commit: r1386726 - in /httpd/httpd/trunk: 
docs/log-message-tags/next-number modules/slotmem/mod_slotmem_shm.c
Date:   Mon, 17 Sep 2012 17:19:45 GMT
From:   j...@apache.org



Author: jim
Date: Mon Sep 17 17:19:44 2012
New Revision: 1386726

URL: http://svn.apache.org/viewvc?rev=1386726view=rev
Log:
Add debug output when slotmem is persisting shm

Modified:
 httpd/httpd/trunk/docs/log-message-tags/next-number
 httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c


Modified: httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c?rev=1386726r1=1386725r2=1386726view=diff

==
--- httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c (original)
+++ httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c Mon Sep 17 17:19:44 2012
@@ -144,6 +144,11 @@ static const char *slotmem_filename(apr_
  return fname;
  }

+static const char *storemem_filename(apr_pool_t *pool, const char *name)
+{
+return apr_pstrcat(pool, name, .persist, NULL);
+}
+
  static void store_slotmem(ap_slotmem_instance_t *slotmem)
  {
  apr_file_t *fp;
@@ -151,7 +156,10 @@ static void store_slotmem(ap_slotmem_ins
  apr_size_t nbytes;
  const char *storename;

-storename = slotmem_filename(slotmem-gpool, slotmem-name);
+storename = storemem_filename(slotmem-gpool, slotmem-name);

Is it really a good idea to replace all the additional stuff slotmem_filename 
does
like taking care of relative filenames or the special handling of none with 
just
a plain apr_pstrcat?
And how is this change related to the comment in the commit log? It seems quite 
more then just doing debug output.

Regards

Rüdiger

Fwd: svn commit: r1387110 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_balancer.c modules

[Rüdiger Plüm]

 Original Message 
Subject:svn commit: r1387110 - in /httpd/httpd/trunk: CHANGES 
docs/manual/mod/mod_proxy.xml include/ap_mmn.h
modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h 
modules/proxy/mod_proxy_balancer.c modules/proxy/proxy_util.c
Date:   Tue, 18 Sep 2012 12:15:51 GMT
From:   j...@apache.org



Author: jim
Date: Tue Sep 18 12:15:50 2012
New Revision: 1387110

URL: http://svn.apache.org/viewvc?rev=1387110view=rev
Log:
Persist local balancer-manager changes across restart/graceful.

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml
 httpd/httpd/trunk/include/ap_mmn.h
 httpd/httpd/trunk/modules/proxy/mod_proxy.c
 httpd/httpd/trunk/modules/proxy/mod_proxy.h
 httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
 httpd/httpd/trunk/modules/proxy/proxy_util.c


Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c?rev=1387110r1=1387109r2=1387110view=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Tue Sep 18 12:15:50 2012
@@ -1145,13 +1145,14 @@ static void * create_proxy_config(apr_po
  #if 0
  id = ap_proxy_hashfunc(apr_psprintf(p, %pp-% APR_TIME_T_FMT, ps, 
apr_time_now()), PROXY_HASHFUNC_DEFAULT);
  #else
-id = ap_proxy_hashfunc(apr_psprintf(p, %pp, ps), PROXY_HASHFUNC_DEFAULT);
+id = ap_proxy_hashfunc(apr_psprintf(p, %pp, s), PROXY_HASHFUNC_DEFAULT);

Wouldn't multiple balancers within the same virtual server end up wit the same 
id now?

Regards

Rüdiger

Fwd: svn commit: r1377475 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_lua.xml docs/manual/style/scripts/prettify.js modules/lua/lua_vmprep.h modules/lua/mod_lua.c modules/lua/mod_lua.h

[Rüdiger Plüm]

 Original Message 
Subject:svn commit: r1377475 - in /httpd/httpd/trunk: CHANGES 
docs/manual/mod/mod_lua.xml
docs/manual/style/scripts/prettify.js modules/lua/lua_vmprep.h 
modules/lua/mod_lua.c modules/lua/mod_lua.h
Date:   Sun, 26 Aug 2012 18:39:59 GMT
From:   humbed...@apache.org



Author: humbedooh
Date: Sun Aug 26 18:39:58 2012
New Revision: 1377475

URL: http://svn.apache.org/viewvc?rev=1377475view=rev
Log:
Add new directives, LuaInputFilter/LuaOutputFilter for creating content filters 
using Lua.

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
 httpd/httpd/trunk/docs/manual/style/scripts/prettify.js
 httpd/httpd/trunk/modules/lua/lua_vmprep.h
 httpd/httpd/trunk/modules/lua/mod_lua.c
 httpd/httpd/trunk/modules/lua/mod_lua.h



Modified: httpd/httpd/trunk/modules/lua/mod_lua.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/mod_lua.c?rev=1377475r1=1377474r2=1377475view=diff
==
--- httpd/httpd/trunk/modules/lua/mod_lua.c (original)
+++ httpd/httpd/trunk/modules/lua/mod_lua.c Sun Aug 26 18:39:58 2012
@@ -55,6 +55,14 @@ typedef struct {

  apr_hash_t *lua_authz_providers;

+typedef struct
+{
+apr_bucket_brigade *tmpBucket;
+lua_State *L;
+ap_lua_vm_spec *spec;
+int broken;
+} lua_filter_ctx;
+

  /**
   * error reporting if lua has an error.
@@ -290,6 +298,281 @@ static int lua_handler(request_rec *r)
  }


+/* --- Input/output content filters --- */
+
+
+static apr_status_t lua_setup_filter_ctx(ap_filter_t* f, request_rec* r, 
lua_filter_ctx**
c) {
+apr_pool_t *pool;
+ap_lua_vm_spec *spec;
+int n, rc;
+lua_State *L;
+lua_filter_ctx *ctx;
+ap_lua_server_cfg *server_cfg = 
ap_get_module_config(r-server-module_config,
+lua_module);
+const ap_lua_dir_cfg *cfg = ap_get_module_config(r-per_dir_config,
+lua_module);
+
+ctx = apr_pcalloc(r-pool, sizeof(lua_filter_ctx));
+ctx-broken = 0;
+*c = ctx;
+/* Find the filter that was called */
+for (n = 0; n  cfg-mapped_filters-nelts; n++) {
+ap_lua_filter_handler_spec *hook_spec =
+((ap_lua_filter_handler_spec **) cfg-mapped_filters-elts)[n];
+
+if (hook_spec == NULL) {
+continue;
+}
+if (!strcasecmp(hook_spec-filter_name, f-frec-name)) {
+spec = create_vm_spec(pool, r, cfg, server_cfg,
+hook_spec-file_name,
+NULL,
+0,
+hook_spec-function_name,
+filter);
+L = ap_lua_get_lua_state(pool, spec, r);
+if (L) {
+L = lua_newthread(L);
+}
+
+if (!L) {
+ap_log_rerror(APLOG_MARK, APLOG_CRIT, 0, r, APLOGNO(01477)
+lua: Failed to obtain lua interpreter for %s 
%s,
+hook_spec-function_name, 
hook_spec-file_name);
+ap_lua_release_state(L, spec, r);
+return APR_EGENERAL;
+}
+if (hook_spec-function_name != NULL) {
+lua_getglobal(L, hook_spec-function_name);
+if (!lua_isfunction(L, -1)) {
+ap_log_rerror(APLOG_MARK, APLOG_CRIT, 0, r, APLOGNO(01478)
+lua: Unable to find function %s in %s,
+hook_spec-function_name,
+hook_spec-file_name);
+ap_lua_release_state(L, spec, r);
+return APR_EGENERAL;
+}
+
+ap_lua_run_lua_request(L, r);
+}
+else {
+int t;
+ap_lua_run_lua_request(L, r);
+
+t = lua_gettop(L);
+lua_setglobal(L, r);
+lua_settop(L, t);
+}
+ctx-L = L;
+ctx-spec = spec;
+
+/* If a Lua filter is interested in filtering a request, it must 
first do a yield,

+ * otherwise we'll assume that it's not interested and pretend we 
didn't find
it.
+ */
+rc = lua_resume(L, 1);
+if (rc == LUA_YIELD) {
+return OK;
+}
+else {
+ap_lua_release_state(L, spec, r);
+return APR_ENOENT;
+}
+}
+}
+return APR_ENOENT;
+}
+
+static apr_status_t lua_output_filter_handle(ap_filter_t *f, 
apr_bucket_brigade *pbbIn) {
+apr_bucket *e;
+request_rec *r = f-r;
+int rc;
+lua_State *L;
+lua_filter_ctx* ctx;
+conn_rec *c = r-connection;
+apr_bucket *pbktIn;
+apr_bucket_brigade *pbbOut = NULL;
+
+/* Set up the initial filter context and acquire the 

Fwd: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua: lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h

[Rüdiger Plüm]

 Original Message 
Subject:svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua: 
lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
Date:   Sun, 05 Aug 2012 19:57:45 GMT
From:   humbed...@apache.org



Author: humbedooh
Date: Sun Aug  5 19:57:44 2012
New Revision: 1369656

URL: http://svn.apache.org/viewvc?rev=1369656view=rev
Log:
Add a server scope for Lua states (in LuaScope), which creates a pool of  
states with manageable
minimum and maximum size.

Modified:
 httpd/httpd/trunk/modules/lua/lua_vmprep.c
 httpd/httpd/trunk/modules/lua/lua_vmprep.h
 httpd/httpd/trunk/modules/lua/mod_lua.c
 httpd/httpd/trunk/modules/lua/mod_lua.h

Modified: httpd/httpd/trunk/modules/lua/lua_vmprep.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_vmprep.c?rev=1369656r1=1369655r2=1369656view=diff
==
--- httpd/httpd/trunk/modules/lua/lua_vmprep.c (original)
+++ httpd/httpd/trunk/modules/lua/lua_vmprep.c Sun Aug  5 19:57:44 2012
@@ -23,6 +23,15 @@

  APLOG_USE_MODULE(lua);

+#if APR_HAS_THREADS
+apr_thread_mutex_t *ap_lua_mutex;
+
+void ap_lua_init_mutex(apr_pool_t *pool, server_rec *s)
+{
+apr_thread_mutex_create(ap_lua_mutex, APR_THREAD_MUTEX_DEFAULT, pool);
+}
+#endif
+

Shouldn't you use the httpd mutex API here to keep the mutex type configureable 
in a generic way?
See util_mutex.c / ap_mutex_register.

Regards

Rüdiger

Fwd: svn commit: r1367725 - /httpd/httpd/trunk/modules/lua/mod_lua.c

[Rüdiger Plüm]

 Original Message 
Subject:svn commit: r1367725 - /httpd/httpd/trunk/modules/lua/mod_lua.c
Date:   Tue, 31 Jul 2012 19:43:30 GMT
From:   humbed...@apache.org



Author: humbedooh
Date: Tue Jul 31 19:43:29 2012
New Revision: 1367725

URL: http://svn.apache.org/viewvc?rev=1367725view=rev
Log:
mod_lua: Add the (missing) LuaMapHandler directive to the fold.
This should work as the existing documentation describes.

Modified:
 httpd/httpd/trunk/modules/lua/mod_lua.c

Modified: httpd/httpd/trunk/modules/lua/mod_lua.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/mod_lua.c?rev=1367725r1=1367724r2=1367725view=diff
==
--- httpd/httpd/trunk/modules/lua/mod_lua.c (original)
+++ httpd/httpd/trunk/modules/lua/mod_lua.c Tue Jul 31 19:43:29 2012
@@ -170,6 +170,35 @@ static ap_lua_vm_spec *create_vm_spec(ap
  return spec;
  }

+static const char* ap_lua_interpolate_string(apr_pool_t* pool, const char* 
string, const
char** values)
+{
+char *stringBetween;
+const char* ret;
+int srclen,x,y;
+srclen = strlen(string);
+ret = ;
+y = 0;
+for (x=0; x  srclen; x++) {
+if (string[x] == '
 x != srclen-1  string[x+1]= '0'
string[x+1]= '9') {
+if (x-y  0) {
+stringBetween = apr_pstrndup(pool, string+y, x-y);
+}
+else stringBetween = ;

Style. Please review the style guide (code should be on the next line)

+int v = atoi(apr_pstrndup(pool,string+x+1, 1));

As this is only one digit you can convert directly, e.g. *(string+x+1) - '0' 
and avoid
copying the string.

+ret = apr_psprintf(pool, %s%s%s, ret, stringBetween, values[v]);

As you only concat strings here use apr_pstrcat here.

+y = ++x;
+}
+}
+
+if (x-y  0  y  0) {
+stringBetween = apr_pstrndup(pool, string+y+1, x-y);
+ret = apr_psprintf(pool, %s%s, ret, stringBetween);


As you only concat strings here use apr_pstrcat here.

+}
+else if (y==0) return string; /* If no replacement was made, just return 
the original
str. */

Style. Please review the style guide (comment should be on a separate line, 
code on the next line)

+return ret;
+}
+
+

Regards

Rüdiger

Fwd: svn commit: r1305192 - /httpd/httpd/branches/2.4.x/build/make_nw_export.awk

[Rüdiger Plüm]

 Original Message 
Subject:svn commit: r1305192 - 
/httpd/httpd/branches/2.4.x/build/make_nw_export.awk
Date:   Mon, 26 Mar 2012 01:36:51 GMT
From:   fua...@apache.org



Author: fuankg
Date: Mon Mar 26 01:36:51 2012
New Revision: 1305192

URL: http://svn.apache.org/viewvc?rev=1305192view=rev
Log:
Fixed broken *_DECLARE_DATA section.
Seems our preprocessor is some crazy and inserts a blank
after replacing a define which made the awk script fail.
Patch submitted by: normw gknw net.



I guess this was already fixed on trunk as well. Mind to mention the revision 
that was backported in the log message?

Regards

Rüdiger

Fwd: svn commit: r1241897 - /httpd/httpd/branches/2.4.x/configure.in

[Rüdiger Plüm]

Author: jim
Date: Wed Feb  8 13:48:19 2012
New Revision: 1241897

URL: http://svn.apache.org/viewvc?rev=1241897view=rev
Log:
Correct the --with_included_apr error message. We no longer provide
an included/bundled version of apr/apu for the convenience of
our users.

Modified:
 httpd/httpd/branches/2.4.x/configure.in

Modified: httpd/httpd/branches/2.4.x/configure.in
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/configure.in?rev=1241897r1=1241896r2=1241897view=diff
==
--- httpd/httpd/branches/2.4.x/configure.in (original)
+++ httpd/httpd/branches/2.4.x/configure.in Wed Feb  8 13:48:19 2012
@@ -88,7 +88,7 @@ APACHE_HELP_STRING(--with-included-apr,U
  if test x$with_included_apr = xyes; then
apr_found=reconfig
if test ! -d srclib/apr; then
-AC_MSG_ERROR([Bundled APR requested but not found at srclib/apr. Download 
and unpack
the corresponding httpd-${HTTPD_VERSION}-deps package over this one.])
+AC_MSG_ERROR([Bundled APR requested but not found at ./srclib/. Download 
and unpack the
corresponding apr and apr-util packages to ./srclib/.])


Hm. Don't we need to mention that the directories should be named apr / 
apr-util whereas untaring the apr / apr-util
sources results in apr-version / apr-util-version directories.

Regards

Rüdiger

Fwd: svn commit: r1238824 - in /httpd/httpd/branches/2.4.x: ./ CHANGES server/core.c

[Rüdiger Plüm]

 Original Message 
Subject:svn commit: r1238824 - in /httpd/httpd/branches/2.4.x: ./ 
CHANGES server/core.c
Date:   Tue, 31 Jan 2012 21:50:03 GMT
From:   s...@apache.org



Author: sf
Date: Tue Jan 31 21:50:03 2012
New Revision: 1238824

URL: http://svn.apache.org/viewvc?rev=1238824view=rev
Log:
Merge r1225199:
Check during configtest that the directories for error logs exist

PR: 29941


Don't we need to backport r1225223 as well?

Regards

Rüdiger

Re: 2.3.15 RewriteRule P

[Rüdiger Plüm]

Eric Covener wrote:
 The different handling of conn-port and conn-hostname doesn't look
 right to me. Can the r-proxyreq check actually be false at this point or is
 it simply redundant? And shouldn't the strcasecmp(conn-hostname,
 uri-hostname) check be done regardless of r-connection-keepalives?
 
 I did not understand the r-keepalives optimization, maybe comparing
 hostnames could just come last.
 

I don't think that this optimization is valid, because this can IMHO lead to
a situation where a non keepalive frontend connection reuses the wrong backend
connection. Keepalives between frontend and backend connections are decoupled.

So it should be simply removed.


Regards

Rüdiger

Fwd: svn commit: r1225199 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/core.c

[Rüdiger Plüm]

 Original-Nachricht 
Betreff:svn commit: r1225199 - in /httpd/httpd/trunk: 
docs/log-message-tags/next-number server/core.c
Datum:  Wed, 28 Dec 2011 14:54:50 GMT
Von:s...@apache.org



Author: sf
Date: Wed Dec 28 14:54:49 2011
New Revision: 1225199

URL: http://svn.apache.org/viewvc?rev=1225199view=rev
Log:
Check during configtest that the directories for error logs exist

Testing under Windows is welcome

PR: 29941

Modified:
httpd/httpd/trunk/docs/log-message-tags/next-number
httpd/httpd/trunk/server/core.c


Modified: httpd/httpd/trunk/server/core.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1225199r1=1225198r2=1225199view=diff
==
--- httpd/httpd/trunk/server/core.c (original)
+++ httpd/httpd/trunk/server/core.c Wed Dec 28 14:54:49 2011
@@ -4342,6 +4342,44 @@ AP_DECLARE(int) ap_sys_privileges_handle
 return sys_privileges;
 }

+static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
+{
+if (s-error_fname[0] == '|'  strcmp(s-error_fname, syslog) == 0)


Doesn't this need to be || instead of?

Regards

Rüdiger

Fwd: svn commit: r1225199 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/core.c

[Rüdiger Plüm]

 Original-Nachricht 
Betreff:svn commit: r1225199 - in /httpd/httpd/trunk: 
docs/log-message-tags/next-number server/core.c
Datum:  Wed, 28 Dec 2011 14:54:50 GMT
Von:s...@apache.org



Author: sf
Date: Wed Dec 28 14:54:49 2011
New Revision: 1225199

URL: http://svn.apache.org/viewvc?rev=1225199view=rev
Log:
Check during configtest that the directories for error logs exist

Testing under Windows is welcome

PR: 29941

Modified:
httpd/httpd/trunk/docs/log-message-tags/next-number
httpd/httpd/trunk/server/core.c


Modified: httpd/httpd/trunk/server/core.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1225199r1=1225198r2=1225199view=diff
==
--- httpd/httpd/trunk/server/core.c (original)
+++ httpd/httpd/trunk/server/core.c Wed Dec 28 14:54:49 2011
@@ -4342,6 +4342,44 @@ AP_DECLARE(int) ap_sys_privileges_handle
 return sys_privileges;
 }

+static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
+{
+if (s-error_fname[0] == '|'  strcmp(s-error_fname, syslog) == 0)


Doesn't this need to be || instead of?

Regards

Rüdiger

Re: CVE-2011-3607, int overflow ap_pregsub()

[Rüdiger Plüm]

Am 21.12.2011 20:08, schrieb Greg Ames:

On Tue, Dec 20, 2011 at 4:26 AM, William A. Rowe Jr.
wr...@rowe-clan.net  wrote:

We should come to a conclusion on this.


How about this for 2.2.x ?

--- server/util.c   (revision 1179624)
+++ server/util.c   (working copy)
@@ -82,6 +82,8 @@
  #define IS_SLASH(s) (s == '/')
  #endif

+/* same as APR_SIZE_MAX which doesn't appear until APR 1.3 */
+#define UTIL_SIZE_MAX (~((apr_size_t)0))

  /*
   * Examine a field value (such as a media-/content-type) string and return
@@ -391,6 +393,11 @@
  len++;
  }
  else if (no  nmatch  pmatch[no].rm_so  pmatch[no].rm_eo) {
+if (UTIL_SIZE_MAX - len= pmatch[no].rm_eo - pmatch[no].rm_so) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, APR_ENOMEM, NULL,
+integer overflow or out of memory condition. );
+return NULL;
+}
  len += pmatch[no].rm_eo - pmatch[no].rm_so;
  }

Is apr 1.3 required for current 2.2.x?  I know it wasn't for older


IMHO APR 1.3 is mandatory for 2.2.x.

Regards

Rüdiger

Re: [RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317)

[Rüdiger Plüm]

Am 24.11.2011 23:37, schrieb Rainer Jung:

On 23.11.2011 15:23, Joe Orton wrote:

Prutha Parikh from Qualys reported a variant on the CVE-2011-3368 attack
against certain mod_proxy/mod_rewrite configurations. A new CVE name,
CVE-2011-4317, has been assigned to this variant.

The configurations in question are the same as affected by -3368, e.g.:

RewriteRule ^(.*) http://www.example.com$1 [P]

and the equivalent ProxyPassMatch. Request examples are:

GET @localhost::8880 HTTP/1.0\r\n\r\n
GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n

These unfortunately do not get trapped in the request parsing trap added
in r1179239, so result in an input to rewrite rule processing which does
not match the URL-path grammar (i.e. does not start with /).

We could try improve that fix, but I think it would be simpler to change
the translate_name hooks in mod_proxy and mod_rewrite to enforce the
requirement in the right place. Other translate_name hooks do this
already.

I propose the patch below. Any comments?

Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c (revision 1179633)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -566,6 +566,13 @@
return OK;
}

+ /* Check that the URI is valid. */
+ if (!r-uri || r-uri[0] != '/') {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ Invalid URI in request %s, r-the_request);
+ return HTTP_BAD_REQUEST;
+ }
+
/* XXX: since r-uri has been manipulated already we're not really
* compliant with RFC1945 at this point. But this probably isn't
* an issue because this is a hybrid proxy/origin server.
Index: modules/mappers/mod_rewrite.c
===
--- modules/mappers/mod_rewrite.c (revision 1179633)
+++ modules/mappers/mod_rewrite.c (working copy)
@@ -4266,6 +4266,13 @@
return DECLINED;
}

+ /* Check that the URI is valid. */
+ if (!r-uri || r-uri[0] != '/') {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ Invalid URI in request %s, r-the_request);
+ return HTTP_BAD_REQUEST;
+ }
+
/*
* add the SCRIPT_URL variable to the env. this is a bit complicated
* due to the fact that apache uses subrequests and internal redirects



Don't know whether that could happen here, but could OPTIONS * be a problem?


I think this is a good point. Should be allowed (and prevented by current patch 
proposal).

Regards

Rüdiger

Re: client_ip vs remote_ip

[Rüdiger Plüm]

Am 24.11.2011 00:27, schrieb William A. Rowe Jr.:

On 11/23/2011 4:39 PM, Nick Kew wrote:


Appropriate Terminology Suggestion:

Object Protocol Remote Name
--  -- 
request_rec HTTP Client client_ip
conn_rec TCP Peer peer_ip


+1




+1

Regards

Rüdiger

Fwd: svn commit: r1204087 - in /httpd/httpd/trunk: include/ap_expr.h include/ap_mmn.h server/util_expr_eval.c server/util_expr_parse.c server/util_expr_parse.y

[Rüdiger Plüm]

 Original-Nachricht 
Betreff: 	svn commit: r1204087 - in /httpd/httpd/trunk: include/ap_expr.h include/ap_mmn.h server/util_expr_eval.c 
server/util_expr_parse.c server/util_expr_parse.y

Datum:  Sat, 19 Nov 2011 21:58:49 GMT
Von:s...@apache.org



Author: sf
Date: Sat Nov 19 21:58:48 2011
New Revision: 1204087

URL: http://svn.apache.org/viewvc?rev=1204087view=rev
Log:
Limit recursion in ap_expr evaluation to avoid unbounded stack usage
* evaluate chains of ||,, and string concatenation non-recursively
* limit other types of recursion to 20 levels
* avoid some string copies if concatenating more than 2 strings

Modified:
httpd/httpd/trunk/include/ap_expr.h
httpd/httpd/trunk/include/ap_mmn.h
httpd/httpd/trunk/server/util_expr_eval.c
httpd/httpd/trunk/server/util_expr_parse.c
httpd/httpd/trunk/server/util_expr_parse.y


Modified: httpd/httpd/trunk/server/util_expr_eval.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_expr_eval.c?rev=1204087r1=1204086r2=1204087view=diff
==
--- httpd/httpd/trunk/server/util_expr_eval.c (original)
+++ httpd/httpd/trunk/server/util_expr_eval.c Sat Nov 19 21:58:48 2011

@@ -657,30 +702,81 @@ static int ap_expr_eval(ap_expr_eval_ctx
 {
 const ap_expr_t *e1 = node-node_arg1;
 const ap_expr_t *e2 = node-node_arg2;
-switch (node-node_op) {
-case op_True:
-return 1;
-case op_False:
-return 0;
-case op_Not:
-return (!ap_expr_eval(ctx, e1));
-case op_Or:
-return (ap_expr_eval(ctx, e1) || ap_expr_eval(ctx, e2));
-case op_And:
-return (ap_expr_eval(ctx, e1)  ap_expr_eval(ctx, e2));
-case op_UnaryOpCall:
-return ap_expr_eval_unary_op(ctx, e1, e2);
-case op_BinaryOpCall:
-return ap_expr_eval_binary_op(ctx, e1, e2);
-case op_Comp:
-if (ctx-info-flags  AP_EXPR_FLAG_SSL_EXPR_COMPAT)
-return ssl_expr_eval_comp(ctx, e1);
-else
-return ap_expr_eval_comp(ctx, e1);
-default:
-*ctx-err = Internal evaluation error: Unknown expression node;
-return FALSE;
+int result = FALSE;
+if (inc_rec(ctx))
+return result;
+while (1) {
+switch (node-node_op) {
+case op_True:
+result ^= TRUE;

Why all these XOR operations and no simple assignments?

+goto out;
+case op_False:
+ctx-reclvl--;

Why this? We already decrement below.

+result ^= FALSE;
+goto out;
+case op_Not:
+result = !result;
+node = e1;
+break;
+case op_Or:
+do {
+if (e1-node_op == op_Not) {
+if (!ap_expr_eval(ctx, e1-node_arg1)) {
+result ^= TRUE;
+goto out;
+}
+}
+else {
+if (ap_expr_eval(ctx, e1)) {
+ctx-reclvl--;


Why this? We already decrement below.

+result ^= TRUE;
+goto out;
+}
+}
+node = node-node_arg2;
+e1 = node-node_arg1;
+} while (node-node_op == op_Or);
+break;
+case op_And:
+do {
+if (e1-node_op == op_Not) {
+if (ap_expr_eval(ctx, e1-node_arg1)) {
+result ^= FALSE;
+goto out;
+}
+}
+else {
+if (!ap_expr_eval(ctx, e1)) {
+result ^= FALSE;
+goto out;
+}
+}
+node = node-node_arg2;
+e1 = node-node_arg1;
+} while (node-node_op == op_And);
+break;
+case op_UnaryOpCall:
+result ^= ap_expr_eval_unary_op(ctx, e1, e2);
+goto out;
+case op_BinaryOpCall:
+result ^= ap_expr_eval_binary_op(ctx, e1, e2);
+goto out;
+case op_Comp:
+if (ctx-info-flags  AP_EXPR_FLAG_SSL_EXPR_COMPAT)
+result ^= ssl_expr_eval_comp(ctx, e1);
+else
+result ^= ap_expr_eval_comp(ctx, e1);
+goto out;
+default:
+*ctx-err = Internal evaluation error: Unknown expression node;
+goto out;
+}
+e1 = node-node_arg1;
+e2 = node-node_arg2;
 }
+out:
+ctx-reclvl--;
+return result;
 }

 AP_DECLARE(int) ap_expr_exec(request_rec *r, const ap_expr_info_t *info,

Fwd: svn commit: r1202257 - in /httpd/httpd/trunk/server/mpm/event: config3.m4 equeue.c equeue.h event.c

[Rüdiger Plüm]

 Original-Nachricht 
Betreff:svn commit: r1202257 - in /httpd/httpd/trunk/server/mpm/event: 
config3.m4 equeue.c equeue.h event.c
Datum:  Tue, 15 Nov 2011 15:51:04 GMT
Von:pque...@apache.org



Author: pquerna
Date: Tue Nov 15 15:51:03 2011
New Revision: 1202257

URL: http://svn.apache.org/viewvc?rev=1202257view=rev
Log:
Create a new lock free circular queue, and use it in the EventMPM to remove the 
timeout mutex
that was wrapping both timeout queue operations and pollset operations.

Added:
httpd/httpd/trunk/server/mpm/event/equeue.c   (with props)
httpd/httpd/trunk/server/mpm/event/equeue.h   (with props)
Modified:
httpd/httpd/trunk/server/mpm/event/config3.m4
httpd/httpd/trunk/server/mpm/event/event.c

Modified: httpd/httpd/trunk/server/mpm/event/config3.m4
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/equeue.c?rev=1202257view=auto
==
--- httpd/httpd/trunk/server/mpm/event/equeue.c (added)
+++ httpd/httpd/trunk/server/mpm/event/equeue.c Tue Nov 15 15:51:03 2011
@@ -0,0 +1,125 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include equeue.h
+
+#includeapr_atomic.h
+#includesched.h
+
+struct ap_equeue_t {
+apr_uint32_t nelem;
+apr_size_t elem_size;
+uint8_t *bytes;
+volatile apr_uint32_t writeCount;
+volatile apr_uint32_t readCount;
+};
+
+
+static APR_INLINE apr_uint32_t count_to_index(ap_equeue_t *eq, apr_uint32_t 
count)
+{
+return (count  (eq-nelem - 1));
+}
+
+static APR_INLINE void* index_to_bytes(ap_equeue_t *eq, apr_uint32_t idx)
+{
+apr_size_t offset = idx * eq-elem_size;
+return (void*)eq-bytes[offset];
+}
+
+static APR_INLINE apr_uint32_t nearest_power(apr_uint32_t num)
+{
+apr_uint32_t n = 1;
+while (n  num) {
+n= 1;
+}
+
+return n;
+}
+
+#if 0
+static void dump_queue(ap_equeue_t *eq)
+{
+apr_uint32_t i;
+
+fprintf(stderr, dumping %p\n, eq);
+fprintf(stderr,   nelem:   %u\n, eq-nelem);
+fprintf(stderr,   esize:   %APR_SIZE_T_FMT\n, eq-elem_size);
+fprintf(stderr,   wcnt:%u\n, eq-writeCount);
+fprintf(stderr,   rcnt:%u\n, eq-writeCount);
+fprintf(stderr,   bytes:   %p\n, eq-bytes);
+for (i = 0; i  eq-nelem; i++) {
+fprintf(stderr, [%u] = %p\n, i, index_to_bytes(eq, i));
+}
+
+fprintf(stderr, \n);
+fflush(stderr);
+}
+#endif
+
+apr_status_t
+ap_equeue_create(apr_pool_t *p, apr_uint32_t nelem, apr_size_t elem_size, 
ap_equeue_t **eqout)
+{
+ap_equeue_t *eq;
+
+*eqout = NULL;
+
+eq = apr_palloc(p, sizeof(ap_equeue_t));
+eq-bytes = apr_palloc(p, (1 + nelem) * elem_size);
+eq-nelem = nearest_power(nelem);
+eq-elem_size = elem_size;
+eq-writeCount = 0;
+eq-readCount = 0;
+*eqout = eq;
+
+return APR_SUCCESS;
+}
+
+void *
+ap_equeue_reader_next(ap_equeue_t *eq)
+{
+if (apr_atomic_read32(eq-writeCount) == eq-readCount) {
+return NULL;
+}
+else {
+apr_uint32_t idx = count_to_index(eq, 
apr_atomic_inc32(eq-readCount));
+return index_to_bytes(eq, idx);
+}
+}
+
+void *
+ap_equeue_writer_value(ap_equeue_t *eq)
+{
+apr_uint32_t idx;
+
+while (1) {
+apr_uint32_t readCount = apr_atomic_read32(eq-readCount);
+
+if (count_to_index(eq, eq-writeCount + 1) != count_to_index(eq, 
readCount)) {
+break;
+}
+/* TODO: research if sched_yield is even worth doing  */
+sched_yield();
+}
+
+idx = count_to_index(eq, eq-writeCount);
+return index_to_bytes(eq, idx);
+}

I assume that only a single thread tries write operations on this queue, 
correct?
Otherwise it seems unsafe if another thread calls
ap_equeue_writer_value in parallel as it would return the same slot until
ap_equeue_writer_onward was called.

Fwd: svn commit: r1202257 - in /httpd/httpd/trunk/server/mpm/event: config3.m4 equeue.c equeue.h event.c

[Rüdiger Plüm]

 Original-Nachricht 
Betreff:svn commit: r1202257 - in /httpd/httpd/trunk/server/mpm/event: 
config3.m4 equeue.c equeue.h event.c
Datum:  Tue, 15 Nov 2011 15:51:04 GMT
Von:pque...@apache.org



Author: pquerna
Date: Tue Nov 15 15:51:03 2011
New Revision: 1202257

URL: http://svn.apache.org/viewvc?rev=1202257view=rev
Log:
Create a new lock free circular queue, and use it in the EventMPM to remove the 
timeout mutex
that was wrapping both timeout queue operations and pollset operations.

Added:
httpd/httpd/trunk/server/mpm/event/equeue.c   (with props)
httpd/httpd/trunk/server/mpm/event/equeue.h   (with props)
Modified:
httpd/httpd/trunk/server/mpm/event/config3.m4
httpd/httpd/trunk/server/mpm/event/event.c


Added: httpd/httpd/trunk/server/mpm/event/equeue.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/equeue.c?rev=1202257view=auto
==
--- httpd/httpd/trunk/server/mpm/event/equeue.c (added)
+++ httpd/httpd/trunk/server/mpm/event/equeue.c Tue Nov 15 15:51:03 2011
@@ -0,0 +1,125 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include equeue.h
+
+#includeapr_atomic.h
+#includesched.h
+
+struct ap_equeue_t {
+apr_uint32_t nelem;
+apr_size_t elem_size;
+uint8_t *bytes;
+volatile apr_uint32_t writeCount;
+volatile apr_uint32_t readCount;
+};
+
+
+static APR_INLINE apr_uint32_t count_to_index(ap_equeue_t *eq, apr_uint32_t 
count)
+{
+return (count  (eq-nelem - 1));
+}
+
+static APR_INLINE void* index_to_bytes(ap_equeue_t *eq, apr_uint32_t idx)
+{
+apr_size_t offset = idx * eq-elem_size;
+return (void*)eq-bytes[offset];
+}
+
+static APR_INLINE apr_uint32_t nearest_power(apr_uint32_t num)
+{
+apr_uint32_t n = 1;
+while (n  num) {
+n= 1;
+}
+
+return n;
+}
+
+#if 0
+static void dump_queue(ap_equeue_t *eq)
+{
+apr_uint32_t i;
+
+fprintf(stderr, dumping %p\n, eq);
+fprintf(stderr,   nelem:   %u\n, eq-nelem);
+fprintf(stderr,   esize:   %APR_SIZE_T_FMT\n, eq-elem_size);
+fprintf(stderr,   wcnt:%u\n, eq-writeCount);
+fprintf(stderr,   rcnt:%u\n, eq-writeCount);
+fprintf(stderr,   bytes:   %p\n, eq-bytes);
+for (i = 0; i  eq-nelem; i++) {
+fprintf(stderr, [%u] = %p\n, i, index_to_bytes(eq, i));
+}
+
+fprintf(stderr, \n);
+fflush(stderr);
+}
+#endif
+
+apr_status_t
+ap_equeue_create(apr_pool_t *p, apr_uint32_t nelem, apr_size_t elem_size, 
ap_equeue_t **eqout)
+{
+ap_equeue_t *eq;
+
+*eqout = NULL;
+
+eq = apr_palloc(p, sizeof(ap_equeue_t));
+eq-bytes = apr_palloc(p, (1 + nelem) * elem_size);
+eq-nelem = nearest_power(nelem);

Shouldn't that be

+eq-nelem = nearest_power(nelem);
+eq-bytes = apr_palloc(p, eq-nelem * elem_size);


instead? Otherwise we might allocate too few elements.

Regards

Rüdiger

Fwd: svn commit: r1200590 - in /httpd/httpd/trunk: buildconf configure.in srclib/libapreq/buildconf srclib/libapreq/configure.in

[Rüdiger Plüm]

 Original-Nachricht 
Betreff: 	svn commit: r1200590 - in /httpd/httpd/trunk: buildconf configure.in srclib/libapreq/buildconf 
srclib/libapreq/configure.in

Datum:  Thu, 10 Nov 2011 21:59:08 GMT
Von:pgollu...@apache.org



Author: pgollucci
Date: Thu Nov 10 21:59:07 2011
New Revision: 1200590

URL: http://svn.apache.org/viewvc?rev=1200590view=rev
Log:
hook up srclib/libapreq to the build system

Modified:
httpd/httpd/trunk/buildconf
httpd/httpd/trunk/configure.in
httpd/httpd/trunk/srclib/libapreq/buildconf
httpd/httpd/trunk/srclib/libapreq/configure.in


This looks like to me that libapreq only works with bundled apr / apr-util and 
not with external ones.
If this assumption is correct, this is IMHO wrong. It should work with external 
APR / APR-UTIL.

Regards

Rüdiger

Fwd: svn commit: r1200040 - in /httpd/httpd/trunk: CHANGES modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h

[Rüdiger Plüm]

 Original-Nachricht 
Betreff: 	svn commit: r1200040 - in /httpd/httpd/trunk: CHANGES modules/ssl/mod_ssl.c modules/ssl/ssl_engine_config.c 
modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_private.h

Datum:  Wed, 09 Nov 2011 23:37:37 GMT
Von:pque...@apache.org



Author: pquerna
Date: Wed Nov  9 23:37:37 2011
New Revision: 1200040

URL: http://svn.apache.org/viewvc?rev=1200040view=rev
Log:
Add support for RFC 5077 TLS Session tickets.  This adds two new directives:

* SSLTicketKeyFile: To store the private information for the encryption of the 
ticket.
* SSLTicketKeyDefault To set the default, otherwise the first listed token is 
used.  This
enables key rotation across servers.

Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/ssl/mod_ssl.c
httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
httpd/httpd/trunk/modules/ssl/ssl_private.h



Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_config.c?rev=1200040r1=1200039r2=1200040view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_config.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_config.c Wed Nov  9 23:37:37 2011

@@ -584,6 +595,62 @@ const char *ssl_cmd_SSLEngine(cmd_parms
 return Argument must be On, Off, or Optional;
 }

+const char *ssl_cmd_SSLTicketKeyDefault(cmd_parms *cmd, void *dcfg, const char 
*name)
+{
+#ifdef HAVE_TLSEXT_TICKETS
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+
+sc-default_ticket_name = name;
+
+return NULL;
+#else
+return TLS Ticket keys are not supported.;
+#endif
+}
+
+const char *ssl_cmd_SSLTicketKeyFile(cmd_parms *cmd, void *dcfg, const char 
*name, const
char *path)
+{
+#ifdef HAVE_TLSEXT_TICKETS
+apr_status_t rv;
+apr_file_t *fp;
+apr_size_t len;
+char buf[TLSEXT_TICKET_KEYLEN];
+modssl_ticket_t* ticket = NULL;
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+
+rv = apr_file_open(fp, path, APR_READ|APR_BINARY,



Why not using ap_server_root_relative on path first?



+   APR_OS_DEFAULT, cmd-temp_pool);
+
+if (rv != APR_SUCCESS) {
+  return apr_psprintf(cmd-pool,
+  Failed to open %s: (%d) %pm,
+  path, rv,rv);
+}
+
+rv = apr_file_read_full(fp,buf[0], TLSEXT_TICKET_KEYLEN,len);
+
+if (rv != APR_SUCCESS) {
+  return apr_psprintf(cmd-pool,
+  Failed to read at least 48 bytes from %s: (%d) %pm,
+  path, rv,rv);
+}
+
+ticket = apr_palloc(cmd-pool, sizeof(modssl_ticket_t));
+
+ticket-conf_name = name;
+
+memcpy(ticket-key_name, buf, 16);
+memcpy(ticket-hmac_secret, buf + 16, 16);
+memcpy(ticket-aes_key, buf + 32, 16);
+
+APR_ARRAY_PUSH(sc-tickets, modssl_ticket_t*) = ticket;
+
+return NULL;
+#else
+return TLS Ticket keys are not supported.;
+#endif
+}
+
 const char *ssl_cmd_SSLFIPS(cmd_parms *cmd, void *dcfg, int flag)
 {
 #ifdef HAVE_FIPS

Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1200040r1=1200039r2=1200040view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Wed Nov  9 23:37:37 2011
@@ -2067,3 +2067,94 @@ static int ssl_find_vhost(void *serverna
 return 0;
 }
 #endif
+
+#ifdef HAVE_TLSEXT_TICKETS
+
+#ifndef tlsext_tick_md
+#ifdef OPENSSL_NO_SHA256
+#define tlsext_tick_md EVP_sha1
+#else
+#define tlsext_tick_md EVP_sha256
+#endif
+#endif
+
+int ssl_callback_tlsext_tickets(SSL *ssl,
+char *keyname,
+char *iv,
+EVP_CIPHER_CTX *cipher_ctx,
+HMAC_CTX *hctx,
+int mode)
+{
+conn_rec *conn  = (conn_rec *)SSL_get_app_data(ssl);
+server_rec *s   = mySrvFromConn(conn);
+SSLSrvConfigRec *sc = mySrvConfig(s);
+
+if (mode == 1) {
+modssl_ticket_t* ticket = sc-default_ticket;
+
+/* Setting up the stuff for encrypting:
+ *  - keyname contains at least 16 bytes we can write to.
+ *  - iv contains at least EVP_MAX_IV_LENGTH (16) bytes we can write 
to.
+ *  - hctx is already allocated, we just need to set the
+ *secret key via HMAC_Init_ex.
+ *  - cipher_ctx is also allocated, and we need to configure
+ *the cipher and private key.
+ */
+
+if (ticket == NULL) {
+/* this should not happen, we always set the default
+  

Fwd: svn commit: r1197405 - in /httpd/httpd/trunk: CHANGES docs/manual/upgrading.xml modules/filters/mod_substitute.c

[Rüdiger Plüm]

 Original-Nachricht 
Betreff:svn commit: r1197405 - in /httpd/httpd/trunk: CHANGES 
docs/manual/upgrading.xml modules/filters/mod_substitute.c
Datum:  Fri, 04 Nov 2011 05:35:54 GMT
Von:s...@apache.org



Author: sf
Date: Fri Nov  4 05:35:53 2011
New Revision: 1197405

URL: http://svn.apache.org/viewvc?rev=1197405view=rev
Log:
To prevent overboarding memory usage, limit line length to 1MB

Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/docs/manual/upgrading.xml
httpd/httpd/trunk/modules/filters/mod_substitute.c

Modified: httpd/httpd/trunk/modules/filters/mod_substitute.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_substitute.c?rev=1197405r1=1197404r2=1197405view=diff
==
--- httpd/httpd/trunk/modules/filters/mod_substitute.c (original)
+++ httpd/httpd/trunk/modules/filters/mod_substitute.c Fri Nov  4 05:35:53 2011
@@ -158,6 +164,9 @@ static void do_pattmatch(ap_filter_t *f,
  * as its own bucket, then isolate the pattern
  * and delete it.
  */
+if (space_left  len + repl_len)
+return APR_ENOMEM;
+space_left -= len + repl_len;


Why is this needed at all? IMHO we only consume memory by creating additional 
bucket structures,
but this does not depend on the length of the replacement strings.
As we use transient buckets below we use the same data (script-replacement) 
over and over
again for new buckets.

 SEDRMPATBCKT(b, len, tmp_b, script-patlen);
 /*
  * Finally, we create a bucket that contains the
@@ -188,25 +197,36 @@ static void do_pattmatch(ap_filter_t *f,
 int left = bytes;
 const char *pos = buff;
 char *repl;
+apr_size_t space_left = AP_SUBST_MAX_LINE_LENGTH;
 while (!ap_regexec_len(script-regexp, pos, left,
AP_MAX_REG_MATCH, regm, 0)) {
+apr_status_t rv;
 have_match = 1;
 if (script-flatten  !force_quick) {
 /* copy bytes before the match */
 if (regm[0].rm_so  0)
 ap_varbuf_strmemcat(vb, pos, regm[0].rm_so);
 /* add replacement string */
-ap_varbuf_regsub(vb, script-replacement, pos,
- AP_MAX_REG_MATCH, regm, 0);
+rv = ap_varbuf_regsub(vb, script-replacement, 
pos,
+  AP_MAX_REG_MATCH, regm,
+  AP_SUBST_MAX_LINE_LENGTH - 
vb.strlen);
+if (rv != APR_SUCCESS)
+return rv;
 }
 else {
-ap_pregsub_ex(pool,repl, script-replacement, pos,
-  AP_MAX_REG_MATCH, regm, 0);
+apr_size_t repl_len;
+rv = ap_pregsub_ex(pool,repl,
+   script-replacement, pos,
+   AP_MAX_REG_MATCH, regm,
+   space_left);
+if (rv != APR_SUCCESS)
+return rv;
 len = (apr_size_t) (regm[0].rm_eo - regm[0].rm_so);
+repl_len = strlen(repl);
+space_left -= len + repl_len;


Isn't it sufficient to reduce space_left only by repl_len?
IMHO we only allocate repl_len new memory in ap_pregsub_ex and not len + 
repl_len or am I wrong here?



 SEDRMPATBCKT(b, regm[0].rm_so, tmp_b, len);
-tmp_b = apr_bucket_transient_create(repl,
- strlen(repl),
- f-r-connection-bucket_alloc);
+tmp_b = apr_bucket_transient_create(repl, repl_len,
+
f-r-connection-bucket_alloc);
 APR_BUCKET_INSERT_BEFORE(b, tmp_b);
 }
 /*

@@ -414,9 +450,8 @@ static apr_status_t substitute_filter(ap
 rv = ap_pass_brigade(f-next, ctx-passbb);
 apr_brigade_cleanup(ctx-passbb);
 num = 0;
-apr_pool_clear(ctx-tpool);



Why don't we clear this pool any longer? It was 

Re: prefetch proxy

[Rüdiger Plüm]

Am 03.11.2011 20:00, schrieb Jim Jagielski:


On Nov 3, 2011, at 2:37 PM, Jeff Trawick wrote:


I'm not disputing that there is some undiagnosed situation where
APR_ETIMEUP is seen.

I am looking for confirmation that APR_ETIMEUP is the expected value.



It's hard to diagnose what the value should be... all I know
is that what is being returned thru APR is EAGAIN, and this
causes issues during the prefetch phase.


But I agree with Jeff that this looks like a bug in APR that should be fixed
there. We should NOT get an EAGAIN here. Only a timeout or something more
fatal (like a closed socket).



For sure, even if we allow EAGAIN, if the underlying condition
still causes a read error, we'll hit it when we really start
reading in the body.

I guess the main idea is that if we're going to prefetch, and
I'm trying to remember why we do, then we should be more
lenient on what we determine as an unrecoverable error. If
we hit EAGAIN and/or TIMEUP, I'm find with logging it and then
breaking out of that loop, even without any retries.


Fine with me for TIMEUP and as a temporary fix for EAGAIN. But we
should find the root cause for EAGAIN.

Regards

Rüdiger

Re: prefetch proxy

[Rüdiger Plüm]

Am 03.11.2011 20:36, schrieb Jim Jagielski:

fwiw: I can recreate this at will...

The setup: the jenkins-cli jarfile with Jenkins running in
Winstone/Jetty/Tomcat/JBoss/Doesn'tMatter and Apache frontending
Jenkins with a ProxyPass.

Trying to access Jenkins thru Apache via:

java jenkins-cli.jar -s http://apache.example.com/

will cause this to happen. The CLI tries to setup a full duplex
link thru apache and when creating the upload channel, apache
will fail with the EAGAIN.

If using haproxy as a front end, the cli works... it ignores the
initial timeout/eagain on the socket and then goes ahead and
reads... you do see the delay, but after the delay, the connection
goes thru.


Hm. Shouldn't the client send an Expect: 100 continue here if it does
not intend to sent the body immediately with the request?
Looks like the current client behaviour is not bug free either
(which does not mean that we should do nothing on httpd side to fix this).

Regards

Rüdiger

Re: prefetch proxy

[Rüdiger Plüm]

Am 01.11.2011 21:23, schrieb Jim Jagielski:

In mod_proxy_http we have:

 /* Prefetch MAX_MEM_SPOOL bytes
  *
  * This helps us avoid any election of C-L v.s. T-E
  * request bodies, since we are willing to keep in
  * memory this much data, in any case.  This gives
  * us an instant C-L election if the body is of some
  * reasonable size.
  */
 temp_brigade = apr_brigade_create(p, bucket_alloc);
 do {
 status = ap_get_brigade(r-input_filters, temp_brigade,
 AP_MODE_READBYTES, APR_BLOCK_READ,
 MAX_MEM_SPOOL - bytes_read);
 if (status != APR_SUCCESS) {
 ap_log_error(APLOG_MARK, APLOG_ERR, status, r-server,
  proxy: prefetch request body failed to %pI (%s)
   from %s (%s),
  p_conn-addr, p_conn-hostname ? p_conn-hostname: ,
  c-remote_ip, c-remote_host ? c-remote_host: );
 return HTTP_BAD_REQUEST;
 }

 apr_brigade_length(temp_brigade, 1,bytes);
 bytes_read += bytes;

However, I see times when status could be APR_EAGAIN. IMO, it doesn't
make sense to error out here in that case. Right?


Why should it be EAGAIN with a blocking read?

Regards

Rüdiger

Re: Really big regex results from ap_pregsub

[Rüdiger Plüm]

Am 13.10.2011 22:30, schrieb William A. Rowe Jr.:

On 10/13/2011 2:32 PM, Jim Jagielski wrote:

We have 2 conditions:

   1. nmatch  AP_MAX_REG_MATCH
   2. really big string

For #1 we can either choose to return NULL or . Since
most calls to ap_pregsub() aren't checked,  might be safer.
And, at least, it indicates an error (or can indicate one).

For #2 we can choose to also limit the returned string size
and only populate the string up to some large but safe limit
OR return NULL OR return 


The largest string value applicable to header values, to URI's
and any presentation string (to errorlog or access log etc) is
MAX_STRING_LEN.  The longest config line is MAX_STRING_LEN.
I don't see a lot of reasons supporting something longer.


This no longer true on trunk. The longest config line is VARBUF_MAX_LEN
which is 16 MB.




All in all, after really mulling it over, using  as our
default error seems safest for pre-2.4. For 2.4, we should
fix our errors to return NULL (and update our own modules
to catch that) and fix that API.


Every case of httpd 2.2 using ap_pregsub is for a header value
or a URI value.  All, that is, except the deprecated mod_substitute.
I'd suggest mod_substitute is the exception, and as this is not
a streaming API, a poor choice of API application.  For that single
case, duplicating the ap_pregsub and tuning it appropriately seems
to be the best choice.  See mod_proxy and mod_include for examples
where ap_pregsub was [appropriately] not used.

To quote the source;

/* This function substitutes for $0-$9, filling in regular expression
  * submatches. Pass it the same nmatch and pmatch arguments that you
  * passed ap_regexec(). pmatch should not be greater than the maximum number
  * of subexpressions - i.e. one more than the re_nsub member of ap_regex_t.
  *
  * input should be the string with the $-expressions, source should be the
  * string that was matched against.
  *
  * It returns the substituted string, or NULL on error.
  *
  * Parts of this code are based on Henry Spencer's regsub(), from his
  * ATT V8 regexp package.
  */

AP_DECLARE(char *) ap_pregsub(apr_pool_t *p, const char *input,
   const char *source, size_t nmatch,
   ap_regmatch_t pmatch[])
{...

This was always unambiguous, NULL on error.  The doxygen has *nothing*
to say about the result value.

So... I'd suggest we fix cases that did not expect NULL and return NULL
on any substitution failure.  I don't even see the need for an MMN bump.



+1

Regards

Rüdiger

Fwd: svn commit: r1179448 - in /httpd/httpd/trunk: include/ap_mmn.h include/mpm_common.h server/mpm_common.c

[Rüdiger Plüm]

 Original-Nachricht 
Betreff: 	svn commit: r1179448 - in /httpd/httpd/trunk: include/ap_mmn.h 
include/mpm_common.h server/mpm_common.c

Datum:  Wed, 05 Oct 2011 21:25:59 GMT
Von:



Author: sf
Date: Wed Oct  5 21:25:58 2011
New Revision: 1179448

URL: http://svn.apache.org/viewvc?rev=1179448view=rev
Log:
Export ap_max_mem_free, needed by r1178079, as pointed out by Gregg L. Smith

Modified:
httpd/httpd/trunk/include/ap_mmn.h
httpd/httpd/trunk/include/mpm_common.h
httpd/httpd/trunk/server/mpm_common.c

Modified: httpd/httpd/trunk/include/ap_mmn.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1179448r1=1179447r2=1179448view=diff
==
--- httpd/httpd/trunk/include/ap_mmn.h (original)
+++ httpd/httpd/trunk/include/ap_mmn.h Wed Oct  5 21:25:58 2011
@@ -355,6 +355,7 @@
  * 20110724.8 (2.3.15-dev) add ap_abort_on_oom(), ap_malloc(), ap_calloc(),
  * ap_realloc()
  * 20110724.9 (2.3.15-dev) add ap_varbuf_pdup() and ap_varbuf_regsub()
+ * 20110724.10(2.3.15-dev) Export ap_max_mem_free
  */

 #define MODULE_MAGIC_COOKIE 0x41503234UL /* AP24 */
@@ -362,7 +363,7 @@
 #ifndef MODULE_MAGIC_NUMBER_MAJOR
 #define MODULE_MAGIC_NUMBER_MAJOR 20110724
 #endif
-#define MODULE_MAGIC_NUMBER_MINOR 9/* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 10   /* 0...n */

 /**
  * Determine if the server's current MODULE_MAGIC_NUMBER is at least a

Modified: httpd/httpd/trunk/include/mpm_common.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/mpm_common.h?rev=1179448r1=1179447r2=1179448view=diff
==
--- httpd/httpd/trunk/include/mpm_common.h (original)
+++ httpd/httpd/trunk/include/mpm_common.h Wed Oct  5 21:25:58 2011
@@ -314,7 +314,7 @@ AP_INIT_TAKE1(GracefulShutdownTimeout,
 int ap_signal_server(int *, apr_pool_t *);
 void ap_mpm_rewrite_args(process_rec *);

-extern apr_uint32_t ap_max_mem_free;
+AP_DECLARE_DATA apr_uint32_t ap_max_mem_free;




Shouldn't that be

extern apr_uint32_t AP_DECLARE_DATA ap_max_mem_free;





 extern const char *ap_mpm_set_max_mem_free(cmd_parms *cmd, void *dummy,
const char *arg);


Modified: httpd/httpd/trunk/server/mpm_common.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm_common.c?rev=1179448r1=1179447r2=1179448view=diff
==
--- httpd/httpd/trunk/server/mpm_common.c (original)
+++ httpd/httpd/trunk/server/mpm_common.c Wed Oct  5 21:25:58 2011
@@ -142,7 +142,7 @@ int ap_max_requests_per_child;
 char ap_coredump_dir[MAX_STRING_LEN];
 int ap_coredumpdir_configured;
 int ap_graceful_shutdown_timeout;
-apr_uint32_t ap_max_mem_free;
+AP_DECLARE_DATA apr_uint32_t ap_max_mem_free;



Shouldn't that be

apr_uint32_t AP_DECLARE_DATA ap_max_mem_free;



 apr_size_t ap_thread_stacksize;

 /* Set defaults for config directives implemented here.  This is

Re: Axe ap_proxy_removestr() ?

[Rüdiger Plüm]

Am 03.10.2011 21:12, schrieb Stefan Fritsch:

Hi,

ap_proxy_removestr() uses memory that grows quadratically with the 
number of fields in the input string, which is bad. It was introduced 
in r88648 (Apr 2001) but hasn't been used after r91370 (Oct 2001). Any 
objection if I just remove it?


Cheers,
Stefan


+1 on trunk.

Regards

Rüdiger

Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h

[Rüdiger Plüm]

On 01/02/2011 12:56 AM, s...@apache.org wrote:
 Author: sf
 Date: Sat Jan  1 23:56:24 2011
 New Revision: 1054323
 
 URL: http://svn.apache.org/viewvc?rev=1054323view=rev
 Log:
 Change the format of the SSL_{CLIENT,SERVER}_{I,S}_DN variables
 to be RFC 2253 compatible, convert non-ASCII characters to UTF8, and 
 escape other special characters with backslashes. The old format can
 still be used with the LegacyDNStringFormat argument to SSLOptions.
 
 Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml
 httpd/httpd/trunk/docs/manual/upgrading.xml
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h
 httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
 httpd/httpd/trunk/modules/ssl/ssl_util_ssl.h

 Modified: httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c?rev=1054323r1=1054322r2=1054323view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c (original)
 +++ httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c Sat Jan  1 23:56:24 2011
 @@ -344,14 +344,32 @@ BOOL SSL_X509_getBC(X509 *cert, int *ca,
  #endif
  }
  
 +/* convert a NAME_ENTRY to UTF8 string */
 +char *SSL_X509_NAME_ENTRY_to_string(apr_pool_t *p, X509_NAME_ENTRY *xsne)
 +{
 +char *result = NULL;
 +BIO* bio;
 +int len;
 +
 +if ((bio = BIO_new(BIO_s_mem())) == NULL)
 +return NULL;
 +ASN1_STRING_print_ex(bio, X509_NAME_ENTRY_get_data(xsne),
 + ASN1_STRFLGS_ESC_CTRL|ASN1_STRFLGS_UTF8_CONVERT);
 +len = BIO_pending(bio);
 +result = apr_palloc(p, len+1);
 +len = BIO_read(bio, result, len);
 +result[len] = NUL;
 +BIO_free(bio);
 +ap_xlate_proto_from_ascii(value, len);

Shouldn't that be ap_xlate_proto_from_ascii(result, len); instead?

Regards

Rüdiger

Re: missing svn properties

[Rüdiger Plüm]

Thanks for the observation. Fixed in r718015.

Regards

Rüdiger

On 11/16/2008 02:23 AM, Takashi Sato wrote:
 In trunk these files are missing svn:eol-style native
 
 docs\manual\mod\mod_buffer.html
 docs\manual\mod\mod_buffer.html.en
 docs\manual\mod\mod_buffer.xml
 docs\manual\mod\mod_buffer.xml.meta
 docs\manual\mod\mod_privileges.html
 docs\manual\mod\mod_privileges.html.en
 docs\manual\mod\mod_privileges.xml
 docs\manual\mod\mod_privileges.xml.meta
 docs\manual\mod\mod_unixd.xml
 docs\manual\mod\mod_unixd.xml.meta
 modules\arch\unix\config5.m4
 modules\arch\unix\mod_privileges.c
 modules\arch\unix\mod_unixd.c
 modules\filters\libsed.h
 modules\filters\mod_buffer.c
 modules\filters\mod_sed.c
 modules\filters\NWGNUmod_request
 modules\filters\regexp.c
 modules\filters\regexp.h
 modules\filters\sed.h
 modules\filters\sed0.c
 modules\filters\sed1.c
 server\mpm\simple\config.m4
 server\mpm\simple\SIMPLE.README
 
 These are missing svn:keywords LastChangedRevision too
  
 docs\manual\mod\mod_buffer.xml
 docs\manual\mod\mod_privileges.xml
 docs\manual\mod\mod_unixd.xml
 
 
 Regards,
 Takashi

Re: Behaviour of mod_proxy_ajp if CPING/CPONG fails

[Rüdiger Plüm]

On 09/05/2008 06:21 PM, Mladen Turk wrote:

Plüm, Rüdiger, VF-Group wrote:
 



+1 for the concept.
However for threaded servers you should call
ap_proxy_acquire_connection inside retry loop, cause there might
be available connections inside the pool.


I don't think that this does what you want. If I simply continue to
acquire connections from the pool without returning the faulty ones
back before, other threads might starve because they cannot get 
connections
from the reslist any longer (not even faulty ones, that they would 
reopen).
If I return the faulty connection to the reslist, there is some 
likelyhood
that I get the same connection back within the next acquire as the 
reslist
is organized as a stack. IMHO this approach would only work if the 
reslist

was organized as a queue, which it is no longer in order to get the ttl
feature in conjunction with smax working correctly.



If failed each connection should be released anyhow, so it's a
loop operation that will either return connection with socket
(potentially valid), or without a socket for reconnect, in which
case you break from the loop in either case.

while (apr_proxy_acguire_connection) {
   fresh = 0
   if (conn-sock == NULL) {
  fresh = 1
   }
   ap_proxy_determine_connection
   ap_proxy_connect_to_backend
   if (!ajp_handle_cping_cpong) {
CPING/CPONG failed. Mark the connection for closure.
conn-close++;
ap_proxy_release_connection
if (fresh) {
   CPING/CPONG failed on fresh connection. bail out.
   return 503;
}
   }
   else {
  CPING/CPONG OK.
  break;
   }
}
go on with socket


As I said: Due to the fact that the reslist is a stack it results effectively 
in the
same thing as my code does. This is because the acquire_connection call will get
the same faulty (but then closed connection) that the previous 
ap_proxy_release_connection
placed back in the reslist.

Regards

Rüdiger

Re: svn commit: r644746 - in /httpd/httpd/trunk: ./ docs/manual/mod/ include/ modules/session/ server/

[Rüdiger Plüm]

On 04/05/2008 05:26 PM, Graham Leggett wrote:

Ruediger Pluem wrote:


+AP_DECLARE(int) ap_unescape_all(char *url);
+
+/**


Doesn't this require a minor bump?


I think it does do, yes. Fixed.


+AP_DECLARE(char *) ap_escape_path_segment_b(char *c, const char *s);


This is not a very descriptive name. Shouldn't it be better 
ap_escape_path_segment_buffer?


It was originally buffer, then I changed it because it was too long. 
You're right though, will change.


Just saw it. I guess you missed to fix the name in the modules that call it.



+AP_DECLARE(void) ap_session_get(request_rec * r, session_rec * z, 
const char *key, const char **value)

+{
+if (!z) {
+ap_session_load(r, z);


Not checking the return value can lead to segfaults as z can be invalid.


The real check is to ensure that z is set, the return value can be 
successful but z can still be NULL (which will happen if no session is

configured), so checking the return value won't help.


Ok, but then we should ensure that z will be at least NULL for proper checking.
AFAICT we do not set *z to NULL in ap_session_load in the case of an error.
So it z may point to an arbitrary location in the memory.

Regards

Rüdiger

Re: Separate mailinglist for doc related bugs?

[Rüdiger Plüm]

Justin Erenkrantz wrote:
 Removed this address from the mailing list...nothing else to see...  --
 justin

Thanks for your help Justin.

Regards

Rüdiger

Re: c-aborted is not set correctly on trunk

[Rüdiger Plüm]

On 01/05/2006 05:24 PM, Joe Orton wrote:
 On Thu, Jan 05, 2006 at 08:14:58AM -0800, Justin Erenkrantz wrote:
 
I do note that the 2.0 code says:

/* The client has aborted, but the request was successful. We
 * will report success, and leave it to the access and error
 * logs to note that the connection was aborted.
 */
return APR_SUCCESS;

This comment is also in 2.2.x. I thought that it was there for good reason,
so I implemented this behaviour again in the patch.


I'm just not sure I agree with that.  -- justin
 
 
 Yes, that little feature is a great source of module bugs so it would 
 be great to remove it.
 
 The problem it works around is really the fact that the default_handler 
 does the bogus trick of returning:
 
 return ap_pass_brigade(r-output_filters, bb);

So I understand that we have two problems here:

1. A non working setting of c-aborted, which should be fixed by the new version
   of the patch, which leaves the return codes as they are. I will commit it
   soon.

2. The behaviour of at least the default_handler to possibly return an APR
   error code if a filter returns non-APR_SUCCESS.

Regards

Rüdiger

Index: server/core_filters.c
===
--- server/core_filters.c   (Revision 366181)
+++ server/core_filters.c   (Arbeitskopie)
@@ -416,6 +416,10 @@
 if (APR_STATUS_IS_EAGAIN(rv)) {
 rv = APR_SUCCESS;
 }
+else if (rv != APR_SUCCESS) {
+/* The client has aborted the connection */
+c-aborted = 1;
+}
 setaside_remaining_output(f, ctx, bb, 0, c);
 return rv;
 }
@@ -430,6 +434,8 @@
 apr_status_t rv = send_brigade_blocking(net-client_socket, bb,
 (ctx-bytes_written), c);
 if (rv != APR_SUCCESS) {
+/* The client has aborted the connection */
+c-aborted = 1;
 return rv;
 }
 bb = remainder;
@@ -464,6 +470,8 @@
 apr_status_t rv = send_brigade_blocking(net-client_socket, bb,
 (ctx-bytes_written), c);
 if (rv != APR_SUCCESS) {
+/* The client has aborted the connection */
+c-aborted = 1;
 return rv;
 }
 }
@@ -471,6 +479,8 @@
 apr_status_t rv = send_brigade_nonblocking(net-client_socket, bb,
(ctx-bytes_written), c);
 if ((rv != APR_SUCCESS)  (!APR_STATUS_IS_EAGAIN(rv))) {
+/* The client has aborted the connection */
+c-aborted = 1;
 return rv;
 }
 }

Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

[Rüdiger Plüm]

On 11/01/2005 04:11 PM, Jim Jagielski wrote:
 Ruediger, would the below appease your sensibilities :)

Yes, it does. I am sorry. I guess I was a little too persistent in
this discussion about this patch of comparable limited influence.
I did not mean to step on your toes and nerves :-).


Regards

Rüdiger

[..cut..]

Re: svn commit: r327601 - /httpd/httpd/branches/2.0.x/STATUS

[Rüdiger Plüm]

On 10/22/2005 12:59 AM, Colm MacCarthaigh wrote:
 On Fri, Oct 21, 2005 at 10:48:23PM -, [EMAIL PROTECTED] wrote:
 
Author: rpluem
Date: Fri Oct 21 15:48:18 2005
New Revision: 327601

URL: http://svn.apache.org/viewcvs?rev=327601view=rev
Log:
* Move two backports from proposed to accepted, as they have enough votes now.
 
 
 I don't think this should be done until the actual code is backported
 too :-)  (someone more clued-in than I can confirm though).
 
 And as obvious as the fix is, I'm not sure if the va_end change has been
 given enough time for someone to potentially object. (though even an
 accepted patch can be vetoed I guess).
 

Sounds reasonable. I will revert this.

Regards

Rüdiger

Re: svn commit: r312964 - in /httpd/httpd/branches/2.2.x: CHANGES modules/proxy/mod_proxy_balancer.c modules/proxy/proxy_util.c

[Rüdiger Plüm]

On 10/12/2005 01:38 PM, Joe Orton wrote:

[..cut..]

 
 
 Yup, if using strchr on a const variable, the correct method to preserve 
 const-ness and avoid those warnings is:
 
   const char *foo;
 
   foo = ap_strchr_c(some_const_char_string, 'x');
 
 note that 'c' would need to be const above too.

Thanks for that info. It took me a while to understand the macros
in util_debug.c / httpd.h (small letter macros OtherBill
just mentioned to dislike :-)).

I think I understand now what is going on and that in DEBUG mode
the strict checking whether const or not is enforced by wrapper
functions whereas in the non debug mode it is a simple macro that
maps things directly to the libc functions which do not do this strict
checking sometimes.
If I understand Jim correctly we should use ap_strchr / ap_strchr_c
throughout the code, but it is not done currently. Maybe I have a look
into this on a rainy day and exchange strchr against ap_strchr / ap_strchr_c
where appropriate :-).


Regards

Rüdiger

Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name

[Rüdiger Plüm]

On 10/11/2005 11:22 PM, Jim Jagielski wrote:
 Ruediger Pluem wrote:
 


On 10/11/2005 09:56 PM, Jim Jagielski wrote:

[..cut..]


+1... I haven't looked to see if there's a better way to
do the 'longest match' test, but that's nit picking :)


Ok, thanks. I think I will commit it tomorrow to trunk and 2.2.x.

 
 
 I can do it if you like...

You did :). Thanks.

Just saw it on #httpd-dev.

BTW: Never seen you there so far.

Regards

Rüdiger

Re: svn commit: r306878 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_connect.c

[Rüdiger Plüm]

On 10/06/2005 10:31 PM, [EMAIL PROTECTED] wrote:
 Author: trawick
 Date: Thu Oct  6 13:31:03 2005
 New Revision: 306878
 
 URL: http://svn.apache.org/viewcvs?rev=306878view=rev

 --- httpd/httpd/trunk/CHANGES [utf-8] (original)
 +++ httpd/httpd/trunk/CHANGES [utf-8] Thu Oct  6 13:31:03 2005
 @@ -31,6 +31,10 @@
  
  Changes with Apache 2.1.9
  
 +  *) mod_proxy_connect: Fix high CPU loop on systems like UnixWare which
 + trigger POLL_ERR or POLL_HUP on a terminated connection.  PR 36951.
 + [Jeff Trawick, Ruediger Pluem]
 +

Sorry for being picky Jeff, but actually you only committed it right now to the 
trunk and not to the 2.2.x
branch from which 2.1.9 will be rolled. So shouldn't your entry be at the top 
of the file?

Regards

Rüdiger

Re: svn commit: r294809 - in /httpd/httpd/trunk: acinclude.m4 configure.in

[Rüdiger Plüm]

On 10/04/2005 06:18 PM, [EMAIL PROTECTED] wrote:
 Author: colm
 Date: Tue Oct  4 09:18:24 2005
 New Revision: 294809

[..cut..]

 
 +
 +AC_CACHE_CHECK([for void pointer length], [ap_void_ptr_lt_long],
 +[AC_TRY_RUN([
 +int main(void)
 +{
 +return sizeof(void *)  sizeof(long); 
 +}], [ap_void_ptr_lt_long=yes], [ap_void_ptr_lt_long=no], 
 +[ap_void_ptr_lt_long=no])])
 +
 +if test $ap_void_ptr_lt_long = no; then
 +AC_MSG_ERROR([Size of void * is less than size of long])
 +fi
 +])
 

[..cut..]

Sorry for being confused by this, but I read your variable name
ap_void_ptr_lt_long as (size of) void ptr is less than (size of) long,
but the assignment of yes and no is exactly the opposite. What about

AC_CACHE_CHECK([for void pointer length], [ap_void_ptr_lt_long],
[AC_TRY_RUN([
int main(void)
{
return sizeof(void *)  sizeof(long);
}], [ap_void_ptr_lt_long=no], [ap_void_ptr_lt_long=yes],
[ap_void_ptr_lt_long=yes])])

if test $ap_void_ptr_lt_long = yes; then
AC_MSG_ERROR([Size of void * is less than size of long])
fi
])

No functional change, but seems clearer to me.

Regards

Rüdiger

Re: svn commit: r293305 - in /httpd/httpd/branches/2.2.x/modules:

[Rüdiger Plüm]

On 10/04/2005 09:32 PM, William A. Rowe, Jr. wrote:
 Brian Candler wrote:
 

[..cut..]

 
 P.S. The reverse case is sillier, given that the value is moving to a
 *larger* type and therefore no data loss can occur:

 short a;
 long b = a;  // (7) no warning

 short a;
 void *b = a; // (8) warns pointer from integer without a
 cast (ok)
 void *c = (void *)a; // (9) warns cast to pointer from integer of
 different size
 void *d = (void *)(long)a;  // (10) even more stupid!!!

 Note that having a 'large enough' integral type in case (10) is not good
 enough. We need to cast 'a' to an integral type which is *exactly* the
 same
 size as a void *, to silence this particular warning.
 
 
 I agree with your assertion that the code example above IS a gcc bug.
 This is expected in C++, but the waning (9) above is completely bogus,

I do not think so. While a does fit in c from the storage point of view
converting c to a different pointer type e.g. (char *) and dereferencing it
afterwards most likely leads to SIGBUS or SIGSEGV. So I think a warning is
justified here.

 as you illustrate with line (7) above.
 

This is different as no harm can be expected here like in (9).

[..cut..]

Regards

Rüdiger

Re: svn commit: r294809 - in /httpd/httpd/trunk: acinclude.m4 configure.in

[Rüdiger Plüm]

On 10/04/2005 10:06 PM, Jim Jagielski wrote:
 Colm MacCarthaigh wrote:
 

[..cut..]

 
 I thought the containers were integral types, not void*. If the containers
 themselves are void*, then the problem is reversed from what I thought,
 but still a valid problem. 

I think we have both problems in the code as we cast void* to integral types
and vice versa.

Regards

Rüdiger

Re: [PATCH] Re: Pluggable mod_log_config

[Rüdiger Plüm]

On 10/03/2005 08:49 PM, Colm MacCarthaigh wrote:
 On Mon, Oct 03, 2005 at 11:40:27AM -0400, Brian Akins wrote:
 

[..cut..]
 
 Looks useful, but file://|/bin/foo would be very non-intuitive for piped

I guess you still can use |/bin/foo because file is the default provider.

 loggers, balancing the backwards compatibility might need a bit more, I
 guess pipe:// or cmd:// schemes might make sense also. 
 

Makes also sense to me since it seems to me that piped logging does not really 
play
well with other things like spread or mysql. On the other side, what about the
buffered logging? Would it make sense to make it possible to turn this on
and off with each provider? If yes, we might should have schemes that say e.g.:

mysql:// for unbuffered mysql backend
mysqlb:// for buffered mysql backend

file:// for unbuffered file backend
fileb:// for buffered file backend

Regards

Rüdiger

Re: [PATCH] Re: Pluggable mod_log_config

[Rüdiger Plüm]

On 10/03/2005 09:11 PM, Brian Akins wrote:
 Rüdiger Plüm wrote:
 
 Makes also sense to me since it seems to me that piped logging does
 not really play
 well with other things like spread or mysql. On the other side, what
 about the
 buffered logging? Would it make sense to make it possible to turn this on
 and off with each provider? If yes, we might should have schemes that
 say e.g.:
 
 
 It seems to me this would be provider specific.

I think buffering is on a higher level and thus it might not be needed
nor useful to reimplement this in every provider. But if we want to
follow this way more strictly we might end up having something like a filter
chain before the provider actually writes the data to its target.
A buffer filter would be the first implementation, but there might be others
like compression or embedded monitoring filters.

 
 
 mysql:// for unbuffered mysql backend
 mysqlb:// for buffered mysql backend
 
 
 Probably, a mysql module would want each line individual, rather than a
 large buffer.

Or it likes to read many lines in one block as it can commit such things
as a batch rather than as single commits per line. Of course it is not required
to use DB transactions on mysql. But for Oracle this might improve performance.

 
 file:// for unbuffered file backend
 fileb:// for buffered file backend
 
 
 
 Or, sticking with the uri methods:
 
 file:///some/log/path?buffered
 
 or maybe:
 
 file://buffered@/some/log/path
 

Hm, the question is how to get all the parameters set with the URL approach 
(thinking
of piped loggers, which you said currently do not seem to work because of the 
spaces).
Maybe as named parameters in the args?
If one likes to follow a filter approach I think URL's would not be useful, but 
to be
honest I currently would have no other idea in this case as the shell approach 
e.g.


Customlog |monitor param=somevalue|buffer size=1024|compress |pipe /bin/foo 
combined

where the last member needs to be a backend provider like pipe, file, mysql.

Regards

Rüdiger

Re: [PATCH] Re: Pluggable mod_log_config

[Rüdiger Plüm]

On 10/03/2005 09:53 PM, Brian Akins wrote:
 Rüdiger Plüm wrote:
 

[..cut..]

 
 but that would not be buffering in the sense that mod_log_config does
 it.  mod_log_config just keeps appending data to a buffer.  in an sql
 logger, to buffer you would keep a list/array/ring of log lines and
 wrap them in a transaction.  This cannot be buffered in mod_log_config

Agreed.

[..cut..]


 See latest patch :)

To be honest I haven't tried it yet, but does apr_uri_parse handle the spaces
between the piped log parameters correctly?
Furthermore I guess you should use

pl = ap_open_piped_log(p, name);

instead of

pl = ap_open_piped_log(p, name + 1);

The | does not prefix name any longer :-).

[..cut..]

 interesting.  You could have a linebuffer that buffered in a way I
 describe above and a buffer that does it the current way.  This may be
  a larger change that we first started.  Of course, you could define a
 log filter chain:
 
 LogFilter example monitor param=somevalue|buffer size=1024|compress|file
 

Sounds like a good idea

 
 and then apply the filter in Custom Log:
 
 CustomeLog filter://example/logs/some.log common
 
 filter could supply /logs/some.log as user_data to each filter.

I guess /logs/some.log is only interesting for the backend. We also
need to consider that backend providers might need totally different (compared 
to filenames)
parameter types. Maybe URL's with args.
I currently found no solution that makes me really happy in conjunction with 
logfilters but
I will keep on thinking on this.

 
 Of course, this is a much larger change than I think we are ready to
 tackle now.


Yes of course. This would require much changes and will not be done in a quick
patch, but it just came up my mind during this discussion and it might be a 
feature to think of.

Regards

Rüdiger

Re: [PATCH] PIE support

[Rüdiger Plüm]

Justin Erenkrantz wrote:
--On Friday, January 21, 2005 2:46 PM + Joe Orton 
[EMAIL PROTECTED] wrote:

Modern versions of GCC/binutils/... support flags which allow building
Position Independent Executables.  This a Security Feature (TM) which
means that executables can be loaded at non-fixed locations, making it
harder to write some types of exploit.
...
Any objections for committing to the trunk?

I'm fine with it in trunk, but I'd be against a 2.0 backport...  -- justin
What is the reason against a backport?
As far as I know (Joe please correct me if I am wrong) it is already used
for the Apache 2.0.x delivered with Red Hat AS 3.0 Upgrade 3 (and maybe 
Fedora???).
So there is actually some test base for running Apache compiled with this 
option.
I was also able to compile my own Apache and run it successfully on Red Hat AS 
3.0
with this compiler option enabled.
As the patch does not seem to make --enable-pie a default and this option only 
works
on systems which have a supporting gcc installed I do not understand why it 
should
not be backported.
Regards
Rdiger

Re: Bug: Apache hangs if script invokes fork/waitpid

[Rüdiger Plüm]

Naik, Roshan wrote:
In my humble opinion it is much simpler (and cleaner) to fix this  
problem in one place...Apache, rather than in each module that may 
face this problem.
I am not sure if it is really simpler (see below) but
admittedly it would make things easier for module authors.


So from the part of the Perl script I see 
only two approaches:

1. Guidelines for script programmers that clearly state that 
you have to call a special
   Perl function for doing a fork inside mod_perl, because 
otherwise you will shoot yourself.

This is unfortunately not feasible (even though possible). The reason
being that there are so many perl modules out there that are being
widely used by programmers. You cant know which function call can 
possibly call a fork(). For example would you ever imagine that Perl's
Syslog module would need to fork ? Well it does... and I was really 
surprised too. That's actually where I noticed this whole problem.
Not only does it call fork() but it seems like its unpredictable as
to when it calls fork(). It seems to do so if we pound on it too 
much. Prusuing this option requires too much knowledge on part of 
Programmers about the internals of the various modules that they 
will be using.
Ok, I do understand your pain and problems better now and I understand
the problems you see with my proposal. So let me try to understand your idea
of a solution inside Apache a little bit better.
If I look at your patch at the end of the mail you would like to exit
the process once the handler has been run. I see the following problems
with that approach:
1. exit(0): This does exactly what you do not like: A function deeper down
   in the call stack terminates the process. Furthermore shared resources
   may no get freed correctly. But this may be fixable by doing it in the same
   way Apache processes handle SIGTERM, SIGHUP and similar signals. So I do
   not see a real big problem here.
2. As fork is called inside the module code Apache gets caught by this
   unprepared. So there may be some locks or similar things on shared resources
   that should be freed before a fork, especially if the fork is used to
   create an additional process for handling a time consuming operation in the
   background.
3. On some Unix OS'es a fork does not copy all threads of the original process
   for performance reasons. So the forked process is not an exact copy of the original
   process. This may lead to problems with multithreaded MPM's.
I think 2. and 3. can only be solved by having an appropriate wrapper around
fork inside of Apache that does the needed preparations. But this would require
that the unknowing module is made to call this wrapper when it calls fork.
On Unix systems I think this is only possible by some ugly and maybe not portable
dynamic linker voodoo. I have no idea how this can be reached on non Unix platforms.
[...]
better support from Apache API functions should be part of 
the further discussion.
As far as I remeber possible approaches like a special 
mod_fork have already been discussed by Jeff and Paul in this thread.

Yes ... and I don't fully understand the scope or the reasoning 
behind those. I still think handling it at Apache level is better
As far as I understand their ideas they also try to carefully prepare
a fork operation. I think their approach is driven from the approaches
used by mod_cgi which also forks processes, but in a big difference
to your problem also executes a new program by calling an exec like
call.
than handling it at content handler. That should also simplify 
the task of writing modules. As a nice side effect a rogue
(or naïve) module will not be able to hang apache.
I think there are enough other approaches left for a rogue module
to reach this :-).
[...]
I dont think it is good idea for a function deeper down in 
the call stack to try to clean up resources allocated by
functions higher up in the call stack. Mod_perl can (and 
should have to) only clean up resources that it has allocated.

For now most of these solutions seem to be aspirational and nothing
concrete likely to materialize soon. For now I would like to propose 
the solution 2 ( in my original email) as a patch. The idea is to invoke 
exit(0) (if we are in the forked worker) just after ap_run_handler is invoked 
by ap_invoke_handler

AP_CORE_DECLARE(int) ap_invoke_handler(request_rec *r)   
{ 
// ...snip

  result = ap_run_handler(r); 

  if ( I am a forked worker ) { 
  exit(0); // terminate at the earliest possible stage after request was processed
  }

// ...snip
}
This solution is a band aid to fix the current shortcoming in design. We
can get rid of this when (if ever) a full fledged solution is worked out. 
I feel it is useful to have this band-aid to stop the bleeding till 
we take it to the hospital.
Sorry, for sounding too sarcastic, simply could not resist:
I am not quite sure if the patient 

Re: Bug: Apache hangs if script invokes fork/waitpid

[Rüdiger Plüm]

Naik, Roshan wrote:
 


-Original Message-
From: Rüdiger Plüm [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 12, 2004 2:45 PM
To: [EMAIL PROTECTED]
Subject: Re: Bug: Apache hangs if script invokes fork/waitpid

[..cut..]
I think 1. is the problem in our case. If you do a fork in 
your perl script you simply create another Apache process 
where your forked perl script is running inside. After the 
forked part of the script has finished its job mod_perl will 
be left and the Apache process will continue doing its normal 
designed work: Waiting for the next request.

I would prefer not to call it as designed to work. It seems
like this situation was not taken into considertaion in the design.
Atleast I don't believe it was designed deliberately so that it would 
hang.
Ok. You are right that for sure it has not been designed to hang. What I mean by
works as designed is that the design does not allow user provided code within
Apache to do a fork without proper preparation. I would not say that it was not
taken into consideration. But I think these are more or less philosophical questions
that drive us away from the real problem and a solution for this problem.
[...]


This behaviour should be totally independent from the MPM you use.

Yes, ideally it should. I am not sure if it is the case though.

So I think mod_perl needs to provide some kind of wrapper for 
the fork command that does the needed cleanups just before 
the real fork is done (as other modules in Apache do that 
fork processes) and that will terminate the process as soon 
as the user provided perl code of this forked process is 
left. So the behaviour will differ from the normal mod_perl 
behaviour (giving control back to the Apache process / thread).


It is not a mod_perl specific problem. It is a problem with any module
like mod_perl. That is a script executed by this module can invoke fork().
You are right that any module trying to do a fork and execute code in the forked
process will experience the same problem, BUT: Modules should not do a fork or allow
code they execute like scripts to do a fork without doing proper pre- and post 
operations.
If they do, it is either a bug of the module or a bug of the script they execute.
Do not get me wrong: I admit that may be there should be some additional
API functions for a module to prepend a fork and cleanly exit this forked
process afterwards. These API function should be usable for the module without
having a knowledge of the running MPM.
You see it is not appropriate to handle this situation in mod_perl. For the
following reasons:
 - mod_perl doesn't really know that the scipt called mod_perl. It hands off the
   script to Perl to interpret and execute. So it is Perl who is acutally calling
   fork()...not mod_perl
This is the real problem: mod_perl does not have real control over what the Perl 
script
does once it handed it over to Perl. As Perl allows you to do many things, there are 
many
ways to harm the Apache process used as a container to run the Perl script. So special 
care
must be taken when writing Perl scripts for mod_perl and if you do not think that the 
script
writers are trustable then mod_perl should provide some kind of sandbox for executing 
the code
to prevent such harmful operations. So from the part of the Perl script I see only two 
approaches:
1. Guidelines for script programmers that clearly state that you have to call a special
   Perl function for doing a fork inside mod_perl, because otherwise you will shoot 
yourself.
2. Create some kind of sandbox for the code running inside mod_perl to prevent the 
code doing
   harmful things like fork in our case. This may be also useful for other 
applications to
   restrict the permissions of a script.
mod_perl on the other side should provide a function that allows the Perl script 
running
inside mod_perl to do a fork in a safe way. Therefore it must embed the real fork 
library / system
call into the correct pre and post operational code. Whether this pre and post 
operational code
should receive better support from Apache API functions should be part of the further 
discussion.
As far as I remeber possible approaches like a special mod_fork have already been 
discussed
by Jeff and Paul in this thread.

 - This means mod_perl needs to know too much about the Apache's internal working. 
   As to whether it should call pthread_exit() or exit() is dependent on the MPM.
As said above this should be encapsulated in appropriate API functions that do not
require the caller to have any knowledge of the MPM running.
 - Secondly mod_perl's decision to terminate could be premature it doesn't give 
   apache any chance to perform any clean ups and other things(if needed).
Of course mod_perl must do the cleanups by calling the appropriate Apache API 
functions before
terminating the process.
[...]
Regards
Rüdiger

[Patch 30399] New directive CacheIgnoreHeaders to prevent user defined headers from being stored by mod_cache

[Rüdiger Plüm]

Hi all,
please find attached a new more general approch to prevent cookies from being stored 
in the cache.
As proposed by Justin I replaced my original CacheStoreCookies directive with the more
general CacheIgnoreHeaders directive. So far I only tested it for myself.
If someone could test / have a look at it, it would be nice and appreciated. Meanwhile 
I try to
get additional testers and will report about the results later.
Regards
Rüdiger
diff -Nrup httpd-2.0.52.orig/docs/manual/mod/mod_cache.xml 
httpd-2.0.52/docs/manual/mod/mod_cache.xml
--- httpd-2.0.52.orig/docs/manual/mod/mod_cache.xml 2004-04-17 20:43:37.0 
+0200
+++ httpd-2.0.52/docs/manual/mod/mod_cache.xml  2004-10-14 23:11:39.0 +0200
@@ -332,4 +332,57 @@ will complete caching the file even if t
 /usage
 /directivesynopsis
 
+directivesynopsis
+nameCacheIgnoreHeaders/name
+descriptionDo not store the given HTTP header(s) in the cache.
+/description
+syntaxCacheIgnoreHeaders varheader-string/var [varheader-string/var] 
.../syntax
+defaultCacheIgnoreHeaders None/default
+contextlistcontextserver config/contextcontextvirtual host/context
+/contextlist
+
+usage
+pAccording to RFC 2616 only hop-by-hop HTTP headers are not stored in
+the cache. The following HTTP headers are hop-by-hop headers and thus
+do not get stored in the cache in emany/em case regardless of the
+setting of directiveCacheIgnoreHeaders/directive:/p
+
+ul
+  licodeConnection/code/li
+  licodeKeep-Alive/code/li
+  licodeProxy-Authenticate/code/li
+  licodeProxy-Authorization/code/li
+  licodeTE/code/li
+  licodeTrailers/code/li
+  licodeTransfer-Encoding/code/li
+  licodeUpgrade/code/li
+/ul
+
+pdirectiveCacheIgnoreHeaders/directive allows to add additional HTTP
+headers that should not to be stored in the cache. For example it makes
+sense in some cases to prevent cookies from being stored in the cache./p
+
+pdirectiveCacheIgnoreHeaders/directive takes a space separated list
+of HTTP headers that should not be stored in the cache. If all none
+hop-by-hop headers should be stored in the cache (RFC 2616 compliant
+behaviour), directiveCacheIgnoreHeaders/directive can be set to
+codeNone/code./p
+
+exampletitleExample 1/title
+  CacheIgnoreHeaders Set-Cookie
+/example
+
+exampletitleExample 2/title
+  CacheIgnoreHeaders None
+/example
+
+note type=warningtitleWarning:/title
+  If headers like codeExpires/code that are needed for the cache
+  management are not stored due to a
+  directiveCacheIgnoreHeaders/directive setting, the behaviour of
+  mod_cache is undefined.
+/note
+/usage
+/directivesynopsis
+
 /modulesynopsis
diff -Nrup httpd-2.0.52.orig/modules/experimental/cache_util.c 
httpd-2.0.52/modules/experimental/cache_util.c
--- httpd-2.0.52.orig/modules/experimental/cache_util.c 2004-08-26 18:59:44.0 
+0200
+++ httpd-2.0.52/modules/experimental/cache_util.c  2004-10-14 20:28:48.0 
+0200
@@ -21,6 +21,8 @@
 
 /* -- */
 
+extern module cache_module;
+
 /* return true if the request is conditional */
 CACHE_DECLARE(int) ap_cache_request_is_conditional(request_rec *r)
 {
@@ -517,8 +519,13 @@ CACHE_DECLARE(char *)generate_name(apr_p
  * headers table that are allowed to be stored in a cache.
  */
 CACHE_DECLARE(apr_table_t *)ap_cache_cacheable_hdrs_out(apr_pool_t *pool,
-apr_table_t *t)
+apr_table_t *t,
+server_rec *s)
 {
+cache_server_conf *conf;
+char **header;
+int i;
+
 /* Make a copy of the headers, and remove from
  * the copy any hop-by-hop headers, as defined in Section
  * 13.5.1 of RFC 2616
@@ -533,5 +540,14 @@ CACHE_DECLARE(apr_table_t *)ap_cache_cac
 apr_table_unset(headers_out, Trailers);
 apr_table_unset(headers_out, Transfer-Encoding);
 apr_table_unset(headers_out, Upgrade);
+conf = (cache_server_conf *)ap_get_module_config(s-module_config,
+ cache_module);
+/* Remove the user defined headers set with CacheIgnoreHeaders.
+ * This may break RFC 2616 compliance on behalf of the users wish.
+ */
+header = (char **)conf-ignore_headers-elts;
+for (i = 0; i  conf-ignore_headers-nelts; i++) {
+apr_table_unset(headers_out, header[i]);
+}
 return headers_out;
 }
diff -Nrup httpd-2.0.52.orig/modules/experimental/mod_cache.c 
httpd-2.0.52/modules/experimental/mod_cache.c
--- httpd-2.0.52.orig/modules/experimental/mod_cache.c  2004-08-26 18:59:44.0 
+0200
+++ httpd-2.0.52/modules/experimental/mod_cache.c   2004-10-14 20:28:48.0 
+0200
@@ -749,6 +749,9 @@ static void * create_cache_config(apr_po
 ps-no_last_mod_ignore = 0;
 

Regeneration of html version of manual from xml

[Rüdiger Plüm]

Hi all,
does anybody know how to regenerate the html version of the manual once I made changes 
to the xml sources of
the manual?
Thanks in advance
Rüdiger

Re: Roadmap Apache 2.1 / 2.2

[Rüdiger Plüm]

Paul Querna wrote:
Rüdiger Plüm wrote:
Hi all,
as some people here are already talking about Apache 2.2, just a short 
question:
Will there ever be a productive version of Apache 2.1 or is it planned to
rename the current Apache 2.1-dev into Apache 2.2.0 as soon as Apache 
2.1-dev is
regarded feature complete and its code having a production grade quality?

More or less, that is correct. Please see:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/VERSIONING?view=markup
Thanks for the link and the quick answer.

Permissions of directories created by mod_disk_cache

[Rüdiger Plüm]

Hi all,
I noticed that the permissions of the directories created by mod_disk_cache are set to
700 whereas the permissions of the files storing the header information respect the
umask and thus have more permissions (at least in my case with my umask).
If this behaviour is intended for security reasons, ok, but if not I am happy to open
a report in bugzilla and provide a patch.
The reason why I would like to see more permissions for the directories:
I run and manage my Apache with two users that share the same group. One user is used
to run Apache, the other one is used to administer Apache (configuration, logfiles).
Tasks that need root permissions are done with sudo. So I would like to have the 
possibility
to inspect these directories (and maybe clean them by hand if needed) with my 
administrative
user. But for this the group needs all permissions.
Regards
Rüdiger

Re: Permissions of directories created by mod_disk_cache

[Rüdiger Plüm]

Jeff Trawick wrote:
On Tue, 05 Oct 2004 14:25:51 +0200, Rüdiger Plüm [EMAIL PROTECTED] wrote:
Hi all,
I noticed that the permissions of the directories created by mod_disk_cache are set to
700 whereas the permissions of the files storing the header information respect the
umask and thus have more permissions (at least in my case with my umask).

Your umask setting can further restrict the permissions specified by
Apache, but it cannot be used to make the permissions more liberal.
That is quite clear. This is the reason why I want Apache to create the 
directories with more
liberal permissions. Users which want to have more strict permissions can use the 
umask to restrict
the permission. My intention was to discuss the following points / questions:
1. If the permissions are more liberal, does this create a default configuration which 
most
   people here would regard as too insecure.
2. As the umask can only be set to one fixed value before the start of Apache using 
the umask
   to restrict the permissions of the directories would also restrict the permissions 
of other
   files created by Apache (especially logfiles). So people might regard the umask 
approach
   to be undesirable.
What permissions do you suggest for the directories?

I would propose the approach to create them with 777 and let the umask do the 
restrictions
(on most systems I guess the umask is at least set to 002 or 022), but 770 would be 
sufficient for me.

Re: Permissions of directories created by mod_disk_cache

[Rüdiger Plüm]

Andreas Steinmetz wrote:
Jeff Trawick wrote:
[..cut..]
Your umask setting can further restrict the permissions specified by
Apache, but it cannot be used to make the permissions more liberal.
What permissions do you suggest for the directories?

If mod_disk_cache still stores authentication credentials (I didn't 
check for a while) on disk I'd strongly suggest to keep 700.
I does not do any longer. mod_cache refuses to cache documents that require
authorization. I think this is also an RFC requirement (Justin, correct?).
BTW: The .headers file which would contain the authorization header is already
created with more liberal permission (I think 666 if the umask is set to 000).

Roadmap Apache 2.1 / 2.2

[Rüdiger Plüm]

Hi all,
as some people here are already talking about Apache 2.2, just a short question:
Will there ever be a productive version of Apache 2.1 or is it planned to
rename the current Apache 2.1-dev into Apache 2.2.0 as soon as Apache 2.1-dev is
regarded feature complete and its code having a production grade quality?
Regards
Rüdiger

Re: [PATCH 21492 30278 30419 31385] Several bugs in mod_cache / mod_disk_cache

[Rüdiger Plüm]

Justin Erenkrantz wrote:
--On Wednesday, September 29, 2004 10:55 AM -0400 Bill Stoddard 
[EMAIL PROTECTED] wrote:

[..cut..]

Well the process is not quite so structured by design, but yes, I plan to
propose we backport these into 2.0 (in time for 2.0.53) and I'll do the
backport as I have time (maybe later this week).

Haha.  Well, it requires three developers to approve a change for 
backporting. And, Bill has been excellent in driving these changes to be 
backported.  I usually prefer to wait until I know that he or someone 
else confirms the commits work for them and don't do anything stupid 
before it even gets proposed.  And, then another developer needs to sign 
off first...

You can help by testing Justin's patch and providing feedback to this 
list.

Absolutely!  Thanks!  -- justin
I just tested Justin's patch(es) by compiling apr-util_20040930041253.tar.gz /
/ apr_20040930041241.tar.gz and httpd-2.0_20040930041734.tar.gz and doing some
tests for the problems that are described in 30278 / 21492. The result of my tests
is that the problem is now fixed by Justin's patches.
As the patch for 30278 has nearly not changed since 2.0.50 I think it is worth 
mentioning that
1. it is used at our company on a production system running 2.0.50 without any problems
   and fixing the problem it has been designed for
2. it has been tested by another user (Igor Fedulov) who opened report 30278
Hope that helps.
Regards
Rüdiger

Re: [PATCH 21492 30278 30419 31385] Several bugs in mod_cache / mod_disk_cache

[Rüdiger Plüm]

Justin Erenkrantz wrote:
--On Tuesday, September 28, 2004 5:28 PM +0200 Rüdiger Plüm 
[EMAIL PROTECTED] wrote:
[..cut..]
Many thanks for the quick response. As I was curious I had a look to the cvs.
Sorry for the maybe stupid question. Do I understand this correctly: You commit the
changes to the main branch (aka. Apache 2.1) and Bill Stoddard backports them to the 
Apache 2.0 branch.
So the fixes for 21492 and 30278 will be part of 2.0.53 if Bill finds time to backport 
them to the
the Apache 2.0 branch before 2.0.53 is released?

23687/30399 which is more an Enhancement than a bug.

As for the patch that you do have, a better way to implement it is to 
have a 3-state variable: UNSET|OFF|ON.  We use that idiom a lot.  It's 
better than adding two variables.  Care to update your patch?
Yes, I will have a look into this. As I am a newbie to Apache programing I used 
the two
other FLAG directives (CacheIgnoreNoLastMod / CacheIgnoreCacheControl) as some kind of
template for my patch. They use two varaibles. Maybe it makes sense to migrate them 
also
to a 3-state variable. I will have a look into this.
Also, I'm wondering if we should extend this directive to be more 
general: i.e. a 'CacheIgnoreHeader' directive?  What do you think?
Yes, this is a nice idea and it had been on my mind as I wrote the patch. I did 
not implement
that because
1. As mentioned above I am a newbie and the implementation of a FLAG directive seemed 
to be easier
   to me than one that takes (multiple) parameters.
2. I am a little worried what happens if this directive is used to ignore headers that 
are needed
   for the correct functionality of mod_cache (e.g. Etag / Content-Type). So maybe it 
is needed to
   have a list of headers that cannot be ignored to prevent stupid configurations. But 
I think
   this leads to the philosophical question how much flexibility should be given to 
the user and
   how much the user should be protected from stupid configurations. So I am 
interested in your thoughts
   on this point.
Nevertheless if the conclusion is made that creating a 'CacheIgnoreHeader' directive 
is a good idea the next
question is how to setup this directive. I would think of something like the Options 
directive that allows
a list of space separated arguments and allows to add or remove single arguments with 
+/- during the merging
of arguments. Any thoughts?

I want to thank you *so* much for summarizing these bugs.  ;-)  I just 
don't have the time to search through Bugzilla.  If you are aware of any 
other mod_cache bugs, please bring them up on [EMAIL PROTECTED]  Thanks!  -- 
I will try to do so.
justin

Regards
Rüdiger

[PATCH 21492 30278 30419 31385] Several bugs in mod_cache / mod_disk_cache

[Rüdiger Plüm]

Hi all,
starting with Apache 2.0.50 I tried to use mod_cache / mod_disk_cache to cache
responses from a Tomcat in the backend on the front web server. Several bugs
(most in mod_disk_cache) prevented me from doing so in a straight forward
manner. So I wrote some patches that fixed these issues and wrote appropriate
bug reports / added comments to existing bug reports in bugzilla. The bug
numbers are
21492
30278
30419
31385
and
23687/30399 which is more an Enhancement than a bug.
As these bugs are still contained in the brand new Apache 2.0.52 I would like
to see them fixed in a future version (maybe 2.0.53 ??) because
1. I think other people could benefit from these fixes as well and some of
   them are really annoying (not just for my case) like 30278 and 21492 or
   31385 introduced with Apache 2.0.51.
2. I am a lazy person who does not like to adjust the patches to new versions
   of Apache ;-)).
So my question now is: Can I do anything else apart from the things I already
did (create / comment reports in bugzilla, add patches) to help these bugs
getting fixed?
I know that the developer resources are short, so if there is something I
can do from my side for fixing these bugs please let me know.
Regards
Rüdiger