Re: svn commit: r1880368 - /httpd/httpd/trunk/docs/manual/style/lang-targets.xml

[Mike Rumph]

Would it be possible to skip the SVN commit diff email?
Like it is possible with [skip ci] to bypass the CI runs.

On Wed, Aug 19, 2020 at 7:35 AM Joe Orton  wrote:

> On Wed, Aug 19, 2020 at 10:08:12AM +0200, Christophe JAILLET wrote:
> > Le 19/08/2020 à 09:47, Joe Orton a écrit :
> > > Stupid question, why do we need to change the suffix to .utf8 to
> convert
> > > these files into UTF-8?
> >
> > I don't think it is needed, just a matter of consistancy in naming.
> > See r1878788 to see the magic needed to concert to UTF-8 (without
> renaming
> > files)
>
> [Adding docs@ to CC.]
>
> Shall we move everything (except for Korean?) to UTF-8 and drop the
> .utf8 suffix as well?  It would still be consistent then.
>
> (I only just renamed those files but, revisions are cheap? ;)
>
> Only problem is the 100-part SVN commit diff e-mail?
>
> Regards, Joe
>
>

Re: svn commit: r1875881 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

[Mike Rumph]

I'm not very familiar with this code, so my questions might not make sense.

But take a look at the following two code segments in
ssl_io_filter_coalesce():

for (e = APR_BRIGADE_FIRST(bb);
 e != APR_BRIGADE_SENTINEL(bb)
 && !APR_BUCKET_IS_METADATA(e)
 && e->length != (apr_size_t)-1
 && e->length < COALESCE_BYTES
 && (buffered + bytes + e->length) < COALESCE_BYTES;

and

if (rv == APR_SUCCESS) {
/* If the read above made the bucket morph, it may now fit
 * entirely within the buffer.  Otherwise, split it so it does
 * fit. */
if (e->length >= COALESCE_BYTES
|| e->length + buffered + bytes >= COALESCE_BYTES) {
rv = apr_bucket_split(e, COALESCE_BYTES - (buffered +
bytes));
}

Does this mean that either buffered or bytes might be negative?
Otherwise, testing both "e->length" and  "e->length + buffered + bytes"
against  COALESCE_BYTES seems redundant.
Just one of these tests should be sufficient.

Also, is it ever possible for "COALESCE_BYTES - (buffered + bytes)" to be
negative?
If so, can the apr_bucket_split() function handle this properly?

Thanks,

Mike




On Wed, Apr 1, 2020 at 12:32 PM Ruediger Pluem  wrote:

>
>
> On 4/1/20 2:38 PM, Joe Orton wrote:
> > On Wed, Apr 01, 2020 at 02:04:21PM +0200, Ruediger Pluem wrote:
> >> On 3/30/20 3:18 PM, jor...@apache.org wrote:
> >>>
> >>> -rv = apr_bucket_split(e, COALESCE_BYTES - (buffered + bytes));
> >>> +/* If the read above made the bucket morph, it may now fit
> >>> + * entirely within the buffer.  Otherwise, split it so it does
> >>> + * fit. */
> >>> +if (e->length < COALESCE_BYTES
> >>> +&& e->length + buffered + bytes < COALESCE_BYTES) {
> >>> +rv = APR_SUCCESS;
> >>
> >> Hmm. If we had e->length == -1 above and the bucket read failed, e
> might still be the morphing bucket and hence e->length == -1.
> >> I think all the code below assumes e->length >= 0 things can get off
> the rails.
> >
> > Thanks a lot for the review... I tried to keep that as simple as
> > possible but there are too many cases to cover.  Yep, you're right.
> >
> >> How about the following patch (minus whitespace changes) to fix this:
> >
> > +1 that looks correct to me, please commit (or I can...)
>
> Committed as r1876014.
>
> Regards
>
> Rüdiger
>

Re: Failed: apache/httpd#484 (2.4.42 - 5ad7f90)

[Mike Rumph]

Build #484 fails on test #484.13, Linux Ubuntu, Regenerate ap_expr
+./buildconf --with-apr=/usr/bin/apr-1-config --with-regen-expr
unknown option  --with-regen-expr
The command "./test/travis run_${TRAVIS_OS_NAME}.sh" exited with 1.

On Thu, Mar 19, 2020 at 8:12 AM Travis CI  wrote:

> apache
>
> /
>
> httpd
>
> 
>
> [image: branch icon]2.4.42 
> [image: build has failed]
> Build #484 failed
> 
> [image: arrow to build time]
> [image: clock icon]9 mins and 41 secs
>
> [image: Daniel Ruggeri avatar]Daniel Ruggeri
> 5ad7f90 CHANGESET → 
>
> Tag HEAD of 2.4.x as 2.4.42
>
> git-svn-id:
> https://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.42@1875426
> 13f79535-47bb-0310-9956-ffa450edef68
>
> Want to know about upcoming build environment updates?
>
> Would you like to stay up-to-date with the upcoming Travis CI build
> environment updates? We set up a mailing list for you!
> SIGN UP HERE 
>
> [image: book icon]
>
> Documentation  about Travis CI
> Have any questions? We're here to help. 
> Unsubscribe
> 
> from build emails from the apache/httpd repository.
> To unsubscribe from *all* build emails, please update your settings
> .
>
> [image: black and white travis ci logo] 
>
> Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy
> Jacops | Contact: cont...@travis-ci.com | Amtsgericht Charlottenburg,
> Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz:
> DE282002648
>

Add an entry in CHANGES file for Travis CI testing

[Mike Rumph]

With the talk of releasing 2.4.42, I was thinking that it might be a good
idea to add some mention of the Travis CI testing that was added in this
release.
Perhaps something in the CHANGES file that gives a summary of the results
achieved by this.
This could include a list of the various platforms and architectures that
were tested.

Mike

Re: Use of [skip ci] in commit messages to avoid Travis builds

[Mike Rumph]

This thread mentions [skip ci] but the Travis issue mentions [ci skip] and
[ci-skip].
Are all of these forms recognized?

On Mon, Feb 10, 2020 at 4:23 AM Eric Covener  wrote:

> On Mon, Feb 10, 2020 at 1:44 AM Ruediger Pluem  wrote:
> >
> >
> >
> > On 02/08/2020 12:01 PM, Luca Toscano wrote:
> > > Hi everybody,
> > >
> > > Travis is able to read commit messages and skip the CI workflow if the
> > > "[skip ci]" magic sequence is added somewhere. I keep forgetting about
> > > it too, but it would be nice if we could start using it to avoid using
> > > CI resources/workers when not needed (like docs changes, entries in
> > > STATUS, etc..). I didn't find a way to instruct Travis to avoid
> > > triggering a build if only certain file types are committed, so the
> > > only solution for the moment is to manually add the aforementioned
> > > sequence :(
> > >
> > > It is not a big deal to trigger builds even for docs etc.., but the
> > > ASF resources/workers are limited (and shared among projects IIUC) so
> > > I am only suggesting to be good neighbors :) If this is totally insane
> > > or unacceptable I'll back off and stop vouching for it I promise!
> > >
> >
> > Thanks for pointing this out, but I forget this as well in many cases
> :-).
> > The only one here who seems to remember this always is IMHO Joe. Maybe
> > he has some tips how we can get better here.
> >
> > Regards
> >
> > Rüdiger
>
> Is there anything possible in SVN like a pre-commit hook that can see
> what changed and append [skip ci] unless some other incantantation is
> present?
>
>
> --
> Eric Covener
> cove...@gmail.com
>

Re: arm64 support for Travis CI testing

[Mike Rumph]

Okay Job #214 has the arm64 run back close to 11 minutes.

On Fri, Jan 10, 2020 at 9:55 AM Mike Rumph  wrote:

> I'm interested in taking a look at this t/apache/expr_string.t testcase
> failure.
> For example, is it the testcase that is in error or is it the code that
> it's testing?
> Maybe this can be discussed in a separate thread since it is not exclusive
> to arm64.
> Has a thread been started on this already?
>
> Also, it looks like the arm64 job is taking close to 30 minutes.
> - https://travis-ci.org/apache/httpd  (Job #213)
> But we have seen earlier jobs close to 11 minutes.
> Has something changed that can explain this?
>
> On Thu, Jan 9, 2020 at 6:12 AM Joe Orton  wrote:
>
>> On Thu, Jan 09, 2020 at 03:01:42PM +0100, Luca Toscano wrote:
>> > Il giorno gio 9 gen 2020 alle ore 14:19 Joe Orton 
>> > ha scritto:
>> > >
>> > > The caching does work on arm64 so the build & test only takes 11
>> minutes
>> > > which is reasonable.
>> > >
>> > > https://travis-ci.org/apache/httpd/jobs/634661216
>> > >
>> > > Looks like this one is the next unreliable test to attack -
>> > >
>> > > 2425# Failed test 17 in t/apache/expr_string.t at line 87
>> > > 2426# Failed test 20 in t/apache/expr_string.t at line 87 fail #2
>> > > 2427t/apache/expr_string.t ..
>> > > 2428Failed 2/44 subtests
>> > > 2429
>> > >
>> > > Can anybody reliably reproduce that failure?
>> >
>> > Does it happen only for ARM or also for other architectures? Never
>> > seen this before..
>>
>> Definitely all architectures, it's one Rainer reports as failing
>> regularly in release testing.  Here's another one and I'm pretty sure it
>> has shown up in more of the recent failures too -
>>
>> https://travis-ci.org/apache/httpd/jobs/633442262
>>
>>

Re: arm64 support for Travis CI testing

[Mike Rumph]

I'm interested in taking a look at this t/apache/expr_string.t testcase
failure.
For example, is it the testcase that is in error or is it the code that
it's testing?
Maybe this can be discussed in a separate thread since it is not exclusive
to arm64.
Has a thread been started on this already?

Also, it looks like the arm64 job is taking close to 30 minutes.
- https://travis-ci.org/apache/httpd  (Job #213)
But we have seen earlier jobs close to 11 minutes.
Has something changed that can explain this?

On Thu, Jan 9, 2020 at 6:12 AM Joe Orton  wrote:

> On Thu, Jan 09, 2020 at 03:01:42PM +0100, Luca Toscano wrote:
> > Il giorno gio 9 gen 2020 alle ore 14:19 Joe Orton 
> > ha scritto:
> > >
> > > The caching does work on arm64 so the build & test only takes 11
> minutes
> > > which is reasonable.
> > >
> > > https://travis-ci.org/apache/httpd/jobs/634661216
> > >
> > > Looks like this one is the next unreliable test to attack -
> > >
> > > 2425# Failed test 17 in t/apache/expr_string.t at line 87
> > > 2426# Failed test 20 in t/apache/expr_string.t at line 87 fail #2
> > > 2427t/apache/expr_string.t ..
> > > 2428Failed 2/44 subtests
> > > 2429
> > >
> > > Can anybody reliably reproduce that failure?
> >
> > Does it happen only for ARM or also for other architectures? Never
> > seen this before..
>
> Definitely all architectures, it's one Rainer reports as failing
> regularly in release testing.  Here's another one and I'm pretty sure it
> has shown up in more of the recent failures too -
>
> https://travis-ci.org/apache/httpd/jobs/633442262
>
>

Re: arm64 support for Travis CI testing

[Mike Rumph]

Okay the first Travis run with arm64 (#201) passed.
The arm64 job (#201.4) took 33 minutes, 5 seconds.
Compared tp ppc64le at 4 minutes, 30 seconds.
This is possibly due to need for extra caching on the first run.
Otherwise, the jobs seem to have the same results.

On Wed, Jan 8, 2020 at 12:13 PM Mike Rumph  wrote:

> Thanks Joe,
>
> Since I'm not adding a new feature other than enabling arm64 support,
> I'll just add the commit directly so that others can contribute as well
> and then revert it if arm64 causes too much noise.
>
> Mike
>
> On Wed, Jan 8, 2020 at 1:00 AM Joe Orton  wrote:
>
>> On Tue, Jan 07, 2020 at 01:27:33PM -0800, Mike Rumph wrote:
>> > I would like to add support for arm64 to httpd/trunk/.travis.yml.
>> > I would then devote some time to getting this support to work.
>> > Are there some steps I should take before adding this commit?
>>
>> That'd be great!  If you are familiar with github & Travis, you could
>> try it using a fork of the git repo, following the instructions in
>> test/README.travis.  Otherwise you could just push the change to trunk
>> and see ;)
>>
>> I can't remember if I tested arm before, but it seems the non-x86 VMs in
>> Travis don't have the same set of Debian packages installed as x86, so
>> some tweaking to the apt: section might be required to get it working.
>>
>> Regards, Joe
>>
>>

Re: arm64 support for Travis CI testing

[Mike Rumph]

Thanks Joe,

Since I'm not adding a new feature other than enabling arm64 support,
I'll just add the commit directly so that others can contribute as well
and then revert it if arm64 causes too much noise.

Mike

On Wed, Jan 8, 2020 at 1:00 AM Joe Orton  wrote:

> On Tue, Jan 07, 2020 at 01:27:33PM -0800, Mike Rumph wrote:
> > I would like to add support for arm64 to httpd/trunk/.travis.yml.
> > I would then devote some time to getting this support to work.
> > Are there some steps I should take before adding this commit?
>
> That'd be great!  If you are familiar with github & Travis, you could
> try it using a fork of the git repo, following the instructions in
> test/README.travis.  Otherwise you could just push the change to trunk
> and see ;)
>
> I can't remember if I tested arm before, but it seems the non-x86 VMs in
> Travis don't have the same set of Debian packages installed as x86, so
> some tweaking to the apt: section might be required to get it working.
>
> Regards, Joe
>
>

arm64 support for Travis CI testing

[Mike Rumph]

I would like to add support for arm64 to httpd/trunk/.travis.yml.
I would then devote some time to getting this support to work.
Are there some steps I should take before adding this commit?

Thanks

Mike Rumph

Re: Trying to compile httpd trunk

[Mike Rumph]

I don't have a way to try this out at the moment,
but if I remember correctly you may want to try ./buildconf inside the
srclib/apr
and srclib/apr-util directories to generate the make files.

On Thu, Dec 19, 2019 at 10:08 AM Stéphane Blondon <
stephane.blon...@gmail.com> wrote:

> Le mar. 17 déc. 2019 à 19:05, Michal Karm Babacek
>  a écrit :
> >
> > The last time I did this (a week or so ago on RHEL 7.6),
> > I had to checkout both apr and apr-util, their 1.x branches, not trunk.
> >
>
> Thanks for your help!
>
> I tried with branches 1.x but it fails with the same error:
>
> $ rm -rf srclib/
> $ make clean
> $ svn co http://svn.apache.org/repos/asf/apr/apr/branches/1.7.x srclib/apr
> $ svn co http://svn.apache.org/repos/asf/apr/apr-util/branches/1.6.x
> srclib/apr-util
> 
> $ ./buildconf
> $ ./configure --prefix=/home/stephane/bin/http --with-included-apr
> $ LANG=C make
>
> Output of `make` command:
> Making all in srclib
> make[1]: Entering directory '/home/stephane/src/httpd-trunk/srclib'
> make[1]: *** No rule to make target 'all'.  Stop.
> make[1]: Leaving directory '/home/stephane/src/httpd-trunk/srclib'
> make: *** [/home/stephane/src/httpd-trunk/build/rules.mk:75:
> all-recursive] Error 1
>
>
> Regards
> --
> Stéphane
>

Re: svn commit: r1805322 - /httpd/httpd/trunk/CHANGES

[Mike Rumph]

On 8/17/2017 11:06 AM, j...@apache.org wrote:

+++ httpd/httpd/trunk/CHANGES [utf-8] Thu Aug 17 18:06:15 2017
@@ -16,6 +16,10 @@ Changes with Apache 2.5.0
*) mod_proxy: loadfactor parameter can now be a decimal number (eg: 1.25).
   [Jim Jagielski]
  
+  *) mod_watchdog/mod_proxy_hcheck: Time intervals can now be spefified

specified

+ down to the millisecond. Supports 'mi' (minute), 'ms' (millisecond),
+ 's' (second) and 'hr' (hour!) time suffixes. [Jim Jagielski]
+

Re: Tool to analyze and minimize loaded modules.

[Mike Rumph]

Hello Christian,

Excellent.  This looks very useful.
And yes.  On second thought, this topic may be more suitable for the 
user mailing list.

There are maybe many Apache users who could benefit from this.
I started it on dev because I was considering developing something on 
this if there wasn't already.

Please, feel free to present this on the user mailing list.

Thanks,

Mike


On 5/18/2017 2:22 PM, Christian Folini wrote:

Hello Mike,

This is probably more a user-ML related question, but I have a little
script to do this in the 2nd of my Apache/ModSecurity tutorials at
https://www.netnea.com/cms/apache-tutorial-2_minimal-apache-configuration/
-> Step 9

Cheers,

Christian


On Mon, May 15, 2017 at 09:12:52AM -0700, Mike Rumph wrote:

Hello all,

I was wondering is there is any tool available that can analyze the
directives in an httpd instance's configuration files and determine which
loaded module are not being used.
If not, maybe such a tool could be quite useful for reducing the memory
footprint.

Thanks,

Mike Rumph

Re: Tool to analyze and minimize loaded modules.

[Mike Rumph]

Thanks Yehuda,

That looks like a good starting point.

On 5/15/2017 10:10 AM, Yehuda Katz wrote:
The server-info handler can give you some of that information, but not 
100%.
It lists each module and the relevant configuration, but mod_info 
itself is an example of that not being enough:
SetHandler server-info is listed in core.c and for me there is no 
configuration listed under mod_info.


I cut this down from the full config to show relevant parts.

Inline image 2

Inline image 1

- Y

On Mon, May 15, 2017 at 12:12 PM, Mike Rumph <mike.ru...@oracle.com 
<mailto:mike.ru...@oracle.com>> wrote:


Hello all,

I was wondering is there is any tool available that can analyze
the directives in an httpd instance's configuration files and
determine which loaded module are not being used.
If not, maybe such a tool could be quite useful for reducing the
memory footprint.

Thanks,

    Mike Rumph

Tool to analyze and minimize loaded modules.

[Mike Rumph]

Hello all,

I was wondering is there is any tool available that can analyze the 
directives in an httpd instance's configuration files and determine 
which loaded module are not being used.
If not, maybe such a tool could be quite useful for reducing the memory 
footprint.


Thanks,

Mike Rumph

Re: Help with task: Websocket documentation

[Mike Rumph]

Sorry my link editor went crazy.
Here are the same links a bit simpler:

- http://httpd.apache.org/docs-project/
- http://httpd.apache.org/docs-project/#ml


On 3/21/2017 7:16 AM, Mike Rumph wrote:

Hello Mohit,

Help with the project is always welcome.
The Apache HTTP Server Documentation Project webpage is a good place 
to start.
- 
https://urldefense.proofpoint.com/v2/url?u=http-3A__httpd.apache.org_docs-2Dproject_=DwICaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=dosEQ8fk2hKexiUuVMoIxUhHLg2PZE9S-ksGD__rCUo=1GlnSrhYIsVBQfxm92CPkEhvQjWMBFugfzwL49SoH4s=g0DAtEpg_-w241LyTIBCvIKfSKmad9yWhHQy8p7FH-w= 



For help on how to contribute documentation, you will want to discuss 
on the docs mailing list:
- 
https://urldefense.proofpoint.com/v2/url?u=http-3A__httpd.apache.org_docs-2Dproject_-23ml=DwICaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=dosEQ8fk2hKexiUuVMoIxUhHLg2PZE9S-ksGD__rCUo=1GlnSrhYIsVBQfxm92CPkEhvQjWMBFugfzwL49SoH4s=54qk0St6t-scuW6oz7GgtMqvd9LFrmCe79mJrdJR0TI= 


Thanks,

Mike

On 3/19/2017 8:08 PM, Mohit Choudhary wrote:
I would like to help out with the task listed at 
https://urldefense.proofpoint.com/v2/url?u=https-3A__helpwanted.apa=DwICaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=dosEQ8fk2hKexiUuVMoIxUhHLg2PZE9S-ksGD__rCUo=1GlnSrhYIsVBQfxm92CPkEhvQjWMBFugfzwL49SoH4s=dWnWg0o6pAmsR19_yAeND46ONeu8h9JQobpqAxhGdQQ= 
che.org/task.html?35d9de95

Re: Help with task: Websocket documentation

[Mike Rumph]

Hello Mohit,

Help with the project is always welcome.
The Apache HTTP Server Documentation Project webpage is a good place to 
start.

- http://httpd.apache.org/docs-project/
For help on how to contribute documentation, you will want to discuss on 
the docs mailing list:

- http://httpd.apache.org/docs-project/#ml

Thanks,

Mike

On 3/19/2017 8:08 PM, Mohit Choudhary wrote:

I would like to help out with the task listed at https://helpwanted.apa
che.org/task.html?35d9de95

Re: svn commit: r1786384 - /httpd/httpd/trunk/server/protocol.c

[Mike Rumph]

On 3/10/2017 8:42 AM, mru...@apache.org wrote:

Author: mrumph
Date: Fri Mar 10 16:42:26 2017
New Revision: 1786384

URL: http://svn.apache.org/viewvc?rev=1786384=rev
Log:
Fix some spelling errors in comments

Modified:
 httpd/httpd/trunk/server/protocol.c

Modified: httpd/httpd/trunk/server/protocol.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1786384=1786383=1786384=diff
==
--- httpd/httpd/trunk/server/protocol.c (original)
+++ httpd/httpd/trunk/server/protocol.c Fri Mar 10 16:42:26 2017
@@ -521,7 +521,7 @@ AP_CORE_DECLARE(void) ap_parse_uri(reque
   *
   * This is not in fact a URI, it's a path.  That matters in the
   * case of a leading double-slash.  We need to resolve the issue
- * by normalising that out before treating it as a URI.
+ * by normalizing that out before treating it as a URI.

This one is actually a difference between British and American English.
I switched the spelling to the American version.
Any objections?

   */
  while ((uri[0] == '/') && (uri[1] == '/')) {
  ++uri ;
@@ -751,7 +751,7 @@ static int read_request_line(request_rec
  *((char *)r->protocol + len) = '\0';
  
  rrl_done:

-/* For internal integrety and palloc efficiency, reconstruct the_request
+/* For internal integrity and palloc efficiency, reconstruct the_request
   * in one palloc, using only single SP characters, per spec.
   */
  r->the_request = apr_pstrcat(r->pool, r->method, *uri ? " " : NULL, uri,
@@ -794,7 +794,7 @@ rrl_done:
  }
  
  /* Determine the method_number and parse the uri prior to invoking error

- * handling, such that these fields are available for subsitution
+ * handling, such that these fields are available for substitution
   */
  r->method_number = ap_method_number_of(r->method);
  if (r->method_number == M_GET && r->method[0] == 'H')
@@ -1057,7 +1057,7 @@ AP_DECLARE(void) ap_get_mime_headers_cor
  else if (last_field != NULL) {
  
  /* Process the previous last_field header line with all obs-folded

- * segments already concatinated (this is not operating on the
+ * segments already concatenated (this is not operating on the
   * most recently read input line).
   */
  

Re: Read scattered to gather send (was [too long]: httpd 2.4.25, mpm_event, ssl: segfaults)

[Mike Rumph]

Hello Yann,

Just one question at this time:
It appears that your changes to httpd will depend on new functions in 
APR-util which would require a new release of APR-util (and APR as well?).

What is your plan for handling this dependency?

Thanks,

Mike Rumph

On 3/3/2017 11:38 AM, Yann Ylavic wrote:

First fix :)

On Fri, Mar 3, 2017 at 6:41 PM, Yann Ylavic <ylavic@gmail.com> wrote:

With apr_allocator_bulk_alloc(), one can request several apr_memnode_t
of a fixed (optional) or minimal given size, and in the worst case get
a single one (allocaœted), or in the best case as much free ones as
available (within a maximal size, also given).

The non-fixed version was buggy (couldn't reuse lower indexes), so
"apr_allocators-bulk-v2.patch" attached.
Will post some numbers (w.r.t. buffers' resuse and writev sizes) soon.

Re: svn commit: r1766129 - in /httpd/httpd/trunk/modules/http2: h2_session.c h2_stream.c

[Mike Rumph]

Okay.  Thanks for the references.

It just seemed a little strange that APR_SUCCESS was explicitly used for 
zero in one place and not in another within the same function.


On 10/24/2016 1:49 PM, Yann Ylavic wrote:

Hi Mike, Jacob,

On Mon, Oct 24, 2016 at 10:04 PM, Jacob Champion <champio...@gmail.com> wrote:

On 10/24/2016 08:54 AM, Mike Rumph wrote:

+return status ? status : rv;

This line seems to depend on the assumption that APR_SUCCESS is coded as
zero.
Wouldn't it be better to not hard code that assumption?

This assumption is pretty deep in APR itself I think (on unix'es it
maps directly to errno).


I certainly hope that APR_SUCCESS is guaranteed to be zero on every
platform, in perpetuum... and from an old conversation [1] on the removal of
the APR_STATUS_IS_SUCCESS macro, it looks like that's the case.

[1]
https://lists.apache.org/thread.html/9b5019c15b1d19f6899141cde46261a3b7c9515e9a7026ce94d1aeb5@1021067744@%3Cdev.apr.apache.org%3E

Another (related) reference:
https://lists.apache.org/thread.html/27267666cba38edb23c93f08e6f769f7b56f3dbc04fd8b4a185e325d@1091059685@%3Cdev.apr.apache.org%3E

So it's a matter of taste actually (usually I omit comparisons to
true/false/NULL only, this time it seems I abused my own rules :)

Regards,
Yann.

Re: Detecting client aborts and stream resets

[Mike Rumph]

Hello Michael.

On 5/3/2016 7:31 AM, Michael Kaufmann wrote:

Hi all,

a content generator module can detect client aborts and stream resets 
while it reads the request body. But how can it detect this 
afterwards, while the response is being generated?


This is important for HTTP/2, because the client may reset a stream, 
and mod_http2 needs to wait for the content generator to finish. 
Therefore the content generator should stop generating the response 
when it is no longer needed.


Is there any API for this? The "conn_rec->aborted" flag exists, but 
which Apache function sets this flag?

The conn_rec->aborted flag is set in the following functions:
- ap_core_output_filter() in server/core_filters.c
- ap_process_connection() in server/connection.c
- process_socket() in server/mpm/event/event.c
- worker_main() in server/mpm/winnt/child.c
If there is no API, maybe an optional function for mod_http2 would be 
a solution.


Regards,
Michael

Re: svn commit: r1741621 - /httpd/httpd/trunk/docs/manual/mod/event.xml

[Mike Rumph]

Added a couple of suggestions below.


On 4/29/2016 5:40 AM, elu...@apache.org wrote:

Author: elukey
Date: Fri Apr 29 12:40:49 2016
New Revision: 1741621

URL: http://svn.apache.org/viewvc?rev=1741621=rev
Log:
Added a specific reference to mpm-event's doc about the fact that mpm-accept is 
not needed anymore

Modified:
 httpd/httpd/trunk/docs/manual/mod/event.xml

Modified: httpd/httpd/trunk/docs/manual/mod/event.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/event.xml?rev=1741621=1741620=1741621=diff
==
--- httpd/httpd/trunk/docs/manual/mod/event.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/event.xml Fri Apr 29 12:40:49 2016
@@ -44,13 +44,13 @@ of consuming threads only for connection
  The worker MPM
  
  

@@ -58,10 +58,10 @@ of the AsyncRequestWorkerFact
  How it Works
  This original goal of this MPM was to fix the 'keep alive problem' in 
HTTP. After a client
  completes the first request, it can keep the connection
-open, sending further requests using the same socket and saving
+open, sending further requests using the same socket and saving
  significant overhead in creating TCP connections. However,
-Apache HTTP Server traditionally keeps an entire child
-process/thread waiting for data from the client, which brings its own 
disadvantages.
+Apache HTTP Server traditionally keeps an entire child
+process/thread waiting for data from the client, which brings its own 
disadvantages.
  To solve this problem, this MPM uses a dedicated listener thread for each 
process
  along with a pool of worker threads, sharing queues specific for those
  requests in keep-alive mode (or, more simply, "readable"), those in write-
@@ -70,7 +70,12 @@ of the AsyncRequestWorkerFact
  adjusts these queues and pushes work to the worker pool.
  
  
-The total amount of connections that a single process/threads block can handle is regulated

+This new architecture, leveraging non blocking sockets and modern kernel

"non" is not a word by itself.  "non blocking" should be "non-blocking".

+   features exposed by APR (like Linux's epoll),
+   does not require anymore the mpm_accept Mutex

1)  "mpm_accept" should be "mpm-accept".
2)  The grammar in "does not require anymore the" seems a bit awkward.
  An easier way to say this is "no longer requires the".

+   configured to avoid the thundering herd problem.
+
+The total amount of connections that a single process/threads block can 
handle is regulated
  by the AsyncRequestWorkerFactor directive.
  
  Async connections

Re: Apache 2.4 adoption revisited -- now 16.4% of Apache sites

[Mike Rumph]

On 2/22/2016 3:40 PM, Luca Toscano wrote:



2016-02-21 15:55 GMT+01:00 Luca Toscano >:



Would it be worth to add a small banner on each documentation page
for 2.2 stating something like:


Patch attached with a very high level idea of what I would like to do. 
I have modified the "retired" banner for 2.2 to suggest the readers a 
migration to 2.4. Wording might not be correct but please let me know 
if you like the idea!


Luca


Hello Luca,

The idea looks good to me.

Here is a first look nitpick at one of the sentences:

"The migration of the configuration files will require a bit of effort 
but it will definitely worth it in term of performances and long term 
maintainability."


==>

The migration of the configuration files will require a bit of effort*,*  but 
it will definitely*be*  worth it in*terms*  of*performance*  and long term 
maintainability.

Thanks,

Mike

Re: svn commit: r1725339 - /httpd/httpd/trunk/docs/manual/index.xml.es

[Mike Rumph]

On 1/18/2016 12:20 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Mon Jan 18 20:20:24 2016
New Revision: 1725339

URL: http://svn.apache.org/viewvc?rev=1725339=rev
Log:
Spanish XML update

Modified:
 httpd/httpd/trunk/docs/manual/index.xml.es

Modified: httpd/httpd/trunk/docs/manual/index.xml.es
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/index.xml.es?rev=1725339=1725338=1725339=diff
==
--- httpd/httpd/trunk/docs/manual/index.xml.es (original)
+++ httpd/httpd/trunk/docs/manual/index.xml.es Mon Jan 18 20:20:24 2016
@@ -1,8 +1,9 @@
  
  
  
-
+
  
+

  

Re: svn commit: r1725339 - /httpd/httpd/trunk/docs/manual/index.xml.es

[Mike Rumph]

Okay.  Thanks.
I thought it would be something like that.

On 1/20/2016 8:09 AM, André Malo wrote:

* Mike Rumph wrote:


Is there some reason why the license information is not translated into
Spanish?

Yes. It would not have any legal power. There is no official translation of
the apache license (AFAIK).

Cheers,
nd

Re: mod_fcgid and broken doc links

[Mike Rumph]

A background for this request can be seen in bug report 56121.
- https://bz.apache.org/bugzilla/show_bug.cgi?id=56121#c4
This bug also describes a manual method for working around this problem.

On 1/12/2016 10:13 AM, Rich Bowen wrote:

mod_fcgid is in a separate repo from the main httpd tree, due to
historical reasons. I presume there are good reasons for this. JimJag
suggested on IRC it's due to its independent release cycle.

Be that as it may, because it uses the standard documentation tools for
the module docs, https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
is full of broken links. In particular, try any of the directive and
links to other modules - try the mod_cgi or AddHandler links in the
intro paragraph, and you'll see immediately what the problem is.

Now, we could of course have a separate version of the docs building
tools just for this module, or we could patch the doc manually, but I
was wondering, if there's no strong current reason for the module to be
kept separate, can we please move it into the main httpd tree?

(Note that exactly the same situation applies to mod_ftp, but there's
just fewer links from that doc so we don't hear it as often.)

--Rich

Re: svn commit: r1723737 - in /httpd/test/mod_h2/trunk: mh2fuzz/h2c_conn.c mh2fuzz/h2c_session.c test/test_frames.sh

[Mike Rumph]

Comment below.

On 1/8/2016 7:26 AM, ic...@apache.org wrote:

Author: icing
Date: Fri Jan  8 15:26:16 2016
New Revision: 1723737

URL: http://svn.apache.org/viewvc?rev=1723737=rev
Log:
normalized frame output for testing

Modified:
 httpd/test/mod_h2/trunk/mh2fuzz/h2c_conn.c
 httpd/test/mod_h2/trunk/mh2fuzz/h2c_session.c
 httpd/test/mod_h2/trunk/test/test_frames.sh

Modified: httpd/test/mod_h2/trunk/mh2fuzz/h2c_conn.c
URL: 
http://svn.apache.org/viewvc/httpd/test/mod_h2/trunk/mh2fuzz/h2c_conn.c?rev=1723737=1723736=1723737=diff
==
--- httpd/test/mod_h2/trunk/mh2fuzz/h2c_conn.c (original)
+++ httpd/test/mod_h2/trunk/mh2fuzz/h2c_conn.c Fri Jan  8 15:26:16 2016
@@ -419,12 +419,14 @@ apr_status_t h2c_conn_shutdown(h2c_conn
  status = apr_socket_shutdown(c->socket, APR_SHUTDOWN_WRITE);
  }
  
-apr_socket_timeout_set(c->socket, apr_time_from_msec(250));

  h2c_conn_want_io(c, H2C_CONN_READ);
  
  if (c->ssl) {

  c->read = tls_shutdown_read;
  }
+
+status = c->read(c);
+status = h2c_conn_close(c);
It seems a bit odd to me to have the status field overlaid like this 
with consecutive calls.

Perhaps you are planning on adding status checking code, correct?

  }
  return status;
  }

Re: OpenSSL 0.9.8/1.0.0 on Trunk

[Mike Rumph]

FYI.  Bug 58737 was just opened today for this error.

Thanks,

Mike

On 12/14/2015 10:15 AM, William A Rowe Jr wrote:

W.r.t. http://svn.apache.org/r1719967 - I'm +1 for the backport.
I'd like to propose we remove all support from *trunk* for OpenSSL < 1.0.1
effective now...

https://mta.openssl.org/pipermail/openssl-announce/2014-December/00.html

We don't deprecate support on maintenance branches (e.g. 2.2/2.4),
because we seek to minimize the pain of moving from one subversion
release to another.  If someone wanted to hack a non-fatal warning for
the ./configure phase, that could be a worthwhile patch.

Re: Upgrade Summary

[Mike Rumph]

Question below:

On 12/10/2015 2:46 AM, Stefan Eissing wrote:

int xxx_switch(conn_rec *c, request_rec *r, server_rec *s,
const char *protocol, int phase)
{
apr_status_t stats;

if (strcmp(my_protocol, protocol)) {

Do you mean "if my_protocol is protocol"?

return DECLINED;
}

if (need_handler && phase != handler) {
return APR_EAGAIN;
}

status = ap_upgrade_request(r, protocol, phase, 
my_additional_header, process_body);
if (status != APR_SUCCESS) {
// any type of error, could also fail if NULL is passed 
instead of
// _body and request has body
return status;
}

// c->output_filters can be written
// c->input_filters can be read, will pass data to 
process_body() until body is done,
// then return data up the filter chain.
process protocol;

return APR_EOF;
}

Re: svn commit: r1717123 - /httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml

[Mike Rumph]

No problem.
I took care of this along with other typos and grammar corrections in 
r1717786 and r1717800.


Thanks,

Mike

On 12/2/2015 10:37 AM, Marion & Christophe JAILLET wrote:

Will fix.
Sorry for not seeing it myself.

CJ

Le 02/12/2015 15:28, Mike Rumph a écrit :

Comment below.

On 11/29/2015 1:00 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Sun Nov 29 21:00:32 2015
New Revision: 1717123

URL: http://svn.apache.org/viewvc?rev=1717123=rev
Log:
Fix doc as spotted by mat in online doc

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml

Modified: httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml?rev=1717123=1717122=1717123=diff
== 


--- httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml Sun Nov 
29 21:00:32 2015

@@ -39,7 +39,7 @@ in order for it to rebuild correctly.
  
-This module makes it easy to restrict what HTTP methods can
+This module makes it easy to restrict what HTTP methods can be
  used on an server. The most common configuration would be:

Should be "on a server".

Re: svn commit: r1717123 - /httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml

[Mike Rumph]

Comment below.

On 11/29/2015 1:00 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Sun Nov 29 21:00:32 2015
New Revision: 1717123

URL: http://svn.apache.org/viewvc?rev=1717123=rev
Log:
Fix doc as spotted by mat in online doc

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml

Modified: httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml?rev=1717123=1717122=1717123=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml Sun Nov 29 21:00:32 
2015
@@ -39,7 +39,7 @@ in order for it to rebuild correctly.
  
  
  

-This module makes it easy to restrict what HTTP methods can
+This module makes it easy to restrict what HTTP methods can be
  used on an server. The most common configuration would be:

Should be "on a server".
  
  

Re: Is Apache getting too patchy?

[Mike Rumph]

Hello Jim,

As Bill pointed out, it would be helpful if you could identify some 
specific details within the general trend you are observing.


But the kind of thing that you are mentioning is something that I would 
expect to happen far more often than can be observed in the Apache HTTP 
Server project.
If individual contributors are each trying to "scratch their own itch", 
then there would be a tendency for code to become less coherent over time.
What keeps things from growing into chaos is the review by experienced 
contributors who are looking at the overall purpose and direction of the 
project as a whole.
Another thing that helps the Apache HTTP Server project is the modular 
design of the code base.  New and diverse features can be isolated into 
separate modules, be given time to mature and then eventually be better 
integrated with the core code.


Over the last few months there simply has been a lot of activity.
But there has also been a lot of quality debate around this activity.
Some very impressive new functionality has been attempted.
I personally have not had enough time (and possibly not enough skill) to 
know if the quality of the code is good or not.  But from my limited 
perspective the discussions seem to be going in a good direction.


Thanks,

Mike Rumph


On 10/24/2015 8:49 AM, Jim Jagielski wrote:

Just some food for thought; let me know if I'm off the rails.

Over the last several months, it's appeared to me that we have
been adding patches that feel, well, very-patchy to me. They
feel like cumbersome add-ons that create some level of fragility
to our code, with special one-off considerations instead of a
deeper more complete fix. In other words, it seems that httpd is
becoming more crufty rather than planned and cohesive and
consistent.

Thoughts? Comments?

Re: svn commit: r1705695 - /httpd/httpd/trunk/docs/manual/mod/mod_h2.xml

[Mike Rumph]

See below:

On 9/28/2015 7:03 AM, Eric Covener wrote:

Modified: httpd/httpd/trunk/docs/manual/mod/mod_h2.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_h2.xml?rev=1705695=1705694=1705695=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_h2.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_h2.xml Mon Sep 28 14:03:27 2015
@@ -35,6 +35,12 @@
  This module relies on http://nghttp2.org/;>libnghttp2
  to provide the core http/2 engine.

+Warning
+  This module is experimental. Its behaviors, directives, and
+  defaults are subject to more frequent and change from release to

more frequent what?

+  release relative to other standard modules. Users are encouraged to
+  consult the "CHANGES" file for potential updates.
+
  

Re: svn commit: r1689694 - /httpd/httpd/trunk/modules/ldap/util_ldap.c

[Mike Rumph]

Comment inline below:
On 7/7/2015 7:43 AM, cove...@apache.org wrote:

Author: covener
Date: Tue Jul  7 14:43:31 2015
New Revision: 1689694

URL: http://svn.apache.org/r1689694
Log:
stuff unexpected LDAP errors into ldc-reason, not just in trace messages.
fix some enormously long lines introduced recently.


Modified:
 httpd/httpd/trunk/modules/ldap/util_ldap.c

Modified: httpd/httpd/trunk/modules/ldap/util_ldap.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ldap/util_ldap.c?rev=1689694r1=1689693r2=1689694view=diff
==
--- httpd/httpd/trunk/modules/ldap/util_ldap.c (original)
+++ httpd/httpd/trunk/modules/ldap/util_ldap.c Tue Jul  7 14:43:31 2015
@@ -1097,7 +1097,9 @@ static int uldap_cache_compare(request_r
  ldc-reason = Comparison no such attribute (cached);
  }
  else {
-ldc-reason = Comparison undefined (cached);
+ldc-reason = apr_psprintf(r-pool,
+  Comparison undefined: (%d): %s 
(adding to cache),
+  result, ldap_err2string(result));
  }
  
  /* record the result code to return with the reason... */

@@ -1105,7 +1107,9 @@ static int uldap_cache_compare(request_r
  /* and unlock this read lock */
  LDAP_CACHE_UNLOCK();
  
-ap_log_rerror(APLOG_MARK, APLOG_TRACE5, 0, r, ldap_compare_s(%pp, %s, %s, %s) = %s (cached), ldc-ldap, dn, attrib, value, ldap_err2string(result));

+ap_log_rerror(APLOG_MARK, APLOG_TRACE5, 0, r,
+  ldap_compare_s(%pp, %s, %s, %s) = %s (cached),
+  ldc-ldap, dn, attrib, value, 
ldap_err2string(result));
  return result;
  }
  }
@@ -1200,11 +1204,16 @@ start_over:
  ldc-reason = Comparison no such attribute (adding to cache);
  }
  else {
+ldc-reason = apr_psprintf(r-pool,
+   Comparison undefined: (%d): %s (adding to 
cache),
+result, ldap_err2string(result));
  ldc-reason = Comparison undefined (adding to cache);

The above line should be removed, correct?

  }
  }
  
-ap_log_rerror(APLOG_MARK, APLOG_TRACE5, 0, r, ldap_compare_s(%pp, %s, %s, %s) = %s, ldc-ldap, dn, attrib, value, ldap_err2string(result));

+ap_log_rerror(APLOG_MARK, APLOG_TRACE5, 0, r,
+  ldap_compare_s(%pp, %s, %s, %s) = %s,
+  ldc-ldap, dn, attrib, value, ldap_err2string(result));
  return result;
  }
  

Re: svn commit: r1687021 - /httpd/httpd/trunk/modules/session/mod_session_dbd.c

[Mike Rumph]

Hello Yann,

This is just a matter of style, but isn't it more typical to have pool 
as the first parameter of a function?
Even in mod_session_dbd.c, this is seen in dbd_clean(), 
session_dbd_monitor(), create_session_dbd_dir_config() and 
merge_session_dbd_dir_config().


Thanks,

Mike
On 6/23/2015 3:54 AM, yla...@apache.org wrote:

Author: ylavic
Date: Tue Jun 23 10:54:15 2015
New Revision: 1687021

URL: http://svn.apache.org/r1687021
Log:
mod_session_dbd: follow up to r1686122.
DBD entries should also have request lifetime.
Proposed by: Jacob Champion jacob.champion ni.com
Reviewed by: ylavic

Modified:
 httpd/httpd/trunk/modules/session/mod_session_dbd.c

Modified: httpd/httpd/trunk/modules/session/mod_session_dbd.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/session/mod_session_dbd.c?rev=1687021r1=1687020r2=1687021view=diff
==
--- httpd/httpd/trunk/modules/session/mod_session_dbd.c (original)
+++ httpd/httpd/trunk/modules/session/mod_session_dbd.c Tue Jun 23 10:54:15 2015
@@ -94,8 +94,11 @@ static apr_status_t dbd_init(request_rec
  
  /**

   * Load the session by the key specified.
+ *
+ * The session value is allocated using the passed apr_pool_t.
   */
-static apr_status_t dbd_load(request_rec * r, const char *key, const char 
**val)
+static apr_status_t dbd_load(request_rec * r, apr_pool_t *pool,
+const char *key, const 
char **val)
  {
  
  apr_status_t rv;

@@ -138,7 +141,7 @@ static apr_status_t dbd_load(request_rec
  return APR_EGENERAL;
  }
  if (*val == NULL) {
-*val = apr_pstrdup(r-pool,
+*val = apr_pstrdup(pool,
 apr_dbd_get_entry(dbd-driver, row, 0));
  }
  /* we can't break out here or row won't get cleaned up */
@@ -204,7 +207,7 @@ static apr_status_t session_dbd_load(req
  /* load an RFC2109 or RFC2965 compliant cookie */
  ap_cookie_read(r, name, key, conf-remove);
  if (key) {
-ret = dbd_load(r, key, val);
+ret = dbd_load(r, m-pool, key, val);
  if (ret != APR_SUCCESS) {
  return ret;
  }
@@ -215,7 +218,7 @@ static apr_status_t session_dbd_load(req
  /* load named session */
  else if (conf-peruser) {
  if (r-user) {
-ret = dbd_load(r, r-user, val);
+ret = dbd_load(r, m-pool, r-user, val);
  if (ret != APR_SUCCESS) {
  return ret;
  }

Re: 2.2 and 2.4 and 2.6/3.0

[Mike Rumph]

The 2.2.x branch is still of interest to the product I work on.
So I am willing to devote effort towards its maintenance.

Thanks,
Mike
On 5/27/2015 7:46 AM, Jeff Trawick wrote:

What we need to know for the 2.2.x branch is basically this:


Developers (committers or not):

[Y] I am willing to help resolve security issues in the 2.2.x branch.
[Y] I am willing to help address non-security issues in the 2.2.x
branch.

PMC members:

[  ] I am willing to test and vote on proposed 2.2.x releases.

Re: svn commit: r1675436 - /httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml

[Mike Rumph]

Hello Eric,

This change gives the following error when ./build.sh validate-xml is run:

Buildfile: build.xml

validate-xml:
[xmlvalidate] 
/home/mrumph/httpd-trunk/docs/manual/mod/mod_authnz_ldap.xml:114:49: 
Attribute name must be declared for element type module.
[xmlvalidate] 
/home/mrumph/httpd-trunk/docs/manual/mod/mod_authnz_ldap.xml:118:28: 
Attribute name must be declared for element type module.


BUILD FAILED
/home/mrumph/httpd-trunk/docs/manual/style/lang-targets.xml:294: 
/home/mrumph/httpd-trunk/docs/manual/mod/mod_authnz_ldap.xml is not a 
valid XML document.


Thanks,

Mike Rumph

On 4/22/2015 10:44 AM, cove...@apache.org wrote:

Author: covener
Date: Wed Apr 22 17:44:00 2015
New Revision: 1675436

URL: http://svn.apache.org/r1675436
Log:
add a prominent caveat about the effect of caching.

PR55089

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml

Modified: httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml?rev=1675436r1=1675435r2=1675436view=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml Wed Apr 22 17:44:00 
2015
@@ -67,8 +67,8 @@ for HTTP Basic authentication./descript
  section id=contentstitleContents/title
  
  ul

-  li
-a href=#operationOperation/a
+  li a href=#gcaveatsGeneral caveats/a /li
+  li a href=#operationOperation/a
  
  ul

lia href=#authenphaseThe Authentication
@@ -109,6 +109,16 @@ for HTTP Basic authentication./descript
  /ul
  /section
  
+section id=gcaveatstitleGeneral caveats/title

+p This module caches authentication and authorization results based
+on the configuration of module name=mod_ldapmod_ldap/module. Changes
+made to the backing LDAP server will not be immediately reflected on the
+HTTP Server, including but not limited to user lockouts/revocations,
+password changes, or changes to group memberships.  Consult the directives
+in module name=mod_ldapmod_ldap/module for details of the cache tunables.
+/p
+/section
+
  section id=operationtitleOperation/title
  
  pThere are two phases in granting access to a user. The first

Re: svn commit: r1675471 - in /httpd/httpd/trunk/docs/manual/mod: core.xml mod_mime.xml

[Mike Rumph]

Hello Eric,

This changed gives the following error when ./build.sh validate-xml is run:

Buildfile: build.xml

validate-xml:
[xmlvalidate] /home/mrumph/httpd-trunk/docs/manual/mod/core.xml:1916:7: 
The element type p must be terminated by the matching end-tag /p.


BUILD FAILED
/home/mrumph/httpd-trunk/docs/manual/style/lang-targets.xml:294: Could 
not validate document /home/mrumph/httpd-trunk/docs/manual/mod/core.xml


Thanks,

Mike

On 4/22/2015 12:37 PM, cove...@apache.org wrote:

Author: covener
Date: Wed Apr 22 19:37:03 2015
New Revision: 1675471

URL: http://svn.apache.org/r1675471
Log:

reword per feedback

Modified:
 httpd/httpd/trunk/docs/manual/mod/core.xml
 httpd/httpd/trunk/docs/manual/mod/mod_mime.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=1675471r1=1675470r2=1675471view=diff
==
--- httpd/httpd/trunk/docs/manual/mod/core.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/core.xml Wed Apr 22 19:37:03 2015
@@ -1892,18 +1892,27 @@ ForceType image/gif
  static files, where the generator of the response typically specifies
  a Content-Type, this directive has no effect./p
  
+

  notetitleNote/title
+pIf no handler is explicitly set for a request, the specified content
+type will also be used as the handler name. /p
+
  pWhen explicit directives such as
  directive module=core SetHandler/directive or
  directive module=mod_mimeAddHandler/directive do not apply
  to the current request, the internal handler name normally set by those
-directives is set to match the content type specified by this directive.
+directives is instead set to the content type specified by this directive.
+p
  This is a historical behavior that some third-party modules
-(such as mod_php) may use magic content types used only to signal the
-module to take responsibility for the matching request.  Configurations
-that rely on such magic types should be avoided by the use of
+(such as mod_php) may look for a synthetic content type used only to
+signal the module to take responsibility for the matching request.
+/p
+
+pConfigurations that rely on such synthetic types should be avoided.
+Additionally, configurations that restrict access to
  directive module=core SetHandler/directive or
-directive module=mod_mimeAddHandler/directive. /p
+directive module=mod_mimeAddHandler/directive should
+restrict access to this directive as well./p
  /note
  
  /usage


Modified: httpd/httpd/trunk/docs/manual/mod/mod_mime.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_mime.xml?rev=1675471r1=1675470r2=1675471view=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_mime.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_mime.xml Wed Apr 22 19:37:03 2015
@@ -610,17 +610,25 @@ AddType application/rss+xml;qs=0.8 .xml
  
  
  notetitleNote/title

+pIf no handler is explicitly set for a request, the specified content
+type will also be used as the handler name. /p
+
  pWhen explicit directives such as
  directive module=core SetHandler/directive or
  directive module=mod_mimeAddHandler/directive do not apply
  to the current request, the internal handler name normally set by those
-directives is set to match the content type specified by this directive.
+directives is instead set to the content type specified by this directive.
+p
  This is a historical behavior that some third-party modules
-(such as mod_php) may use magic content types used only to signal the
-module to take responsibility for the matching request.  Configurations
-that rely on such magic types should be avoided by the use of
+(such as mod_php) may look for a synthetic content type used only to
+signal the module to take responsibility for the matching request.
+/p
+
+pConfigurations that rely on such synthetic types should be avoided.
+Additionally, configurations that restrict access to
  directive module=core SetHandler/directive or
-directive module=mod_mimeAddHandler/directive. /p
+directive module=mod_mimeAddHandler/directive should
+restrict access to this directive as well./p
  /note
  
  /usage

Re: fast sequential requests under event

[Mike Rumph]

Hello Yann,

I am quite sure that Eric's comment was meant as the best of compliments.
It should be quite obvious to most Apache HTTP Server developer's over 
the last year

that you have been quite active and productive.
I probably speak for the majority in saying that the rest of wish
that we had your skill, time and enthusiasm for the project.

Please, keep up the good work!

Take care,

Mike Rumph

On 3/27/2015 3:44 PM, Yann Ylavic wrote:

On Fri, Mar 27, 2015 at 1:27 PM, Jim Jagielski j...@jagunet.com wrote:

On Mar 26, 2015, at 9:28 AM, Eric Covener cove...@gmail.com wrote:

That is certainly less code then Ed's proof of concept -- how
uncharacteristic of you :)


LOL!

Yes, I know, was not in great shape, but if I had known Ed was ahead,
I certainly would have shown my full potential :)

That said, I'm not sure how I should take this, warning, advice, kind
sarcasm, both?
I'm very open to suggestions/blame when I over/shouldn't commit
things, and won't be offended if a revert or another-way-to-do-it is
asked (any pointer?).

I also prefer oneliners when applicable, for sure (less
work/surprise), but sometimes things need to be be fixed completely
(and/or evolutively), at least in trunk.
It also appears that trunk and 2.4 should be kept in sync as much as
possible, that's kind of paradox which sometimes may lead to half
fixes/improvements.
Maybe I tend to fix and evolve (the related) too much at the same
time, or else I just overdo everything (I try hard not to, though)...

There are yet several multi-liners proposals which were not acked,
or lost, although fixing real issues (IMHO).
I commited some of them already (I guess you noticed these), and would
like to the same for the others ( I'll ping on the corresponding
threads first ;)
So don't hesitate to ring the bell, no offense, that's how it works!

Re: svn commit: r1653941 - in /httpd/httpd/trunk: CHANGES docs/manual/expr.xml docs/manual/mod/mod_alias.xml modules/mappers/mod_alias.c

[Mike Rumph]

On 1/22/2015 9:02 AM, minf...@apache.org wrote:

==
--- httpd/httpd/trunk/modules/mappers/mod_alias.c (original)
+++ httpd/httpd/trunk/modules/mappers/mod_alias.c Thu Jan 22 17:02:22 2015
@@ -34,6 +34,7 @@
  #include http_config.h
  #include http_request.h
  #include http_log.h
+#include ap_expr.h
  
  
  typedef struct {

@@ -50,11 +51,20 @@ typedef struct {
  } alias_server_conf;
  
  typedef struct {

+int alias_set:1;
+int redirect_set:1;
  apr_array_header_t *redirects;
+const ap_expr_info_t *alias;
+char *handler;
+const ap_expr_info_t *redirect;
+int redirect_status;/* 301, 302, 303, 410, etc */
  } alias_dir_conf;

It might be preferred to use unsigned int for bit fields as is used in 
mod_proxy.h.
IIRC there have been past discussions on problems resulting from signed 
bit fields.

Re: svn commit: r1611169 - in /httpd/httpd/trunk: CHANGES server/mpm/winnt/service.c

[Mike Rumph]

Hello Bill,

Sorry to respond to this so late, but I see that this is up for a vote 
against httpd 2.4.

I noticed a possible problem in the code.
I have a question inserted below.

Thanks,

Mike Rumph

On 7/16/2014 1:15 PM, wr...@apache.org wrote:

Author: wrowe
Date: Wed Jul 16 20:15:49 2014
New Revision: 1611169

URL: http://svn.apache.org/r1611169
Log:
mpm_winnt: Accept utf-8 (Unicode) service names and descriptions for
internationalization.

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/server/mpm/winnt/service.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1611169r1=1611168r2=1611169view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Wed Jul 16 20:15:49 2014
@@ -1,6 +1,12 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.0
  
+  *) mpm_winnt: Accept utf-8 (Unicode) service names and descriptions for

+ internationalization.  [William Rowe]
+
+  *) mpm_winnt: Normalize the error and status messages emitted by service.c,
+ the service control interface for Windows.  [William Rowe]
+
*) SECURITY: CVE-2013-5704 (cve.mitre.org)
   core: HTTP trailers could be used to replace HTTP headers
   late during request processing, potentially undoing or

Modified: httpd/httpd/trunk/server/mpm/winnt/service.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/winnt/service.c?rev=1611169r1=1611168r2=1611169view=diff
==
--- httpd/httpd/trunk/server/mpm/winnt/service.c (original)
+++ httpd/httpd/trunk/server/mpm/winnt/service.c Wed Jul 16 20:15:49 2014
@@ -21,11 +21,18 @@
  
  #define _WINUSER_
  
+#include apr.h

+#include apr_strings.h
+#include apr_lib.h
+#if APR_HAS_UNICODE_FS
+#include arch/win32/apr_arch_utf8.h
+#include arch/win32/apr_arch_misc.h
+#include wchar.h
+#endif
+
  #include httpd.h
  #include http_log.h
  #include mpm_winnt.h
-#include apr_strings.h
-#include apr_lib.h
  #include ap_regkey.h
  
  #ifdef NOUSER

@@ -41,6 +48,10 @@ APLOG_USE_MODULE(mpm_winnt);
  static char *mpm_service_name = NULL;
  static char *mpm_display_name = NULL;
  
+#if APR_HAS_UNICODE_FS

+static apr_wchar_t *mpm_service_name_w;
+#endif
+
  typedef struct nt_service_ctx_t
  {
  HANDLE mpm_thread;   /* primary thread handle of the apache server */
@@ -57,6 +68,32 @@ static nt_service_ctx_t globdat;
  static int ReportStatusToSCMgr(int currentState, int waitHint,
 nt_service_ctx_t *ctx);
  
+/* Rather than repeat this logic throughout, create an either-or wide or narrow

+ * implementation because we don't actually pass strings to OpenSCManager.
+ * This election is based on build time defines and runtime os version test.
+ */
+#undef OpenSCManager
+typedef SC_HANDLE (WINAPI *fpt_OpenSCManager)(const void *lpMachine,
+  const void *lpDatabase,
+  DWORD dwAccess);
+static fpt_OpenSCManager pfn_OpenSCManager = NULL;
+static APR_INLINE SC_HANDLE OpenSCManager(const void *lpMachine,
+  const void *lpDatabase,
+  DWORD dwAccess)
+{
+if (!pfn_OpenSCManager) {
+#if APR_HAS_UNICODE_FS
+IF_WIN_OS_IS_UNICODE
+pfn_OpenSCManager = (fpt_OpenSCManager)OpenSCManagerW;
+#endif
+#if APR_HAS_ANSI_FS
+ELSE_WIN_OS_IS_ANSI
+pfn_OpenSCManager = (fpt_OpenSCManager)OpenSCManagerA;
+#endif
+}
+return (*(pfn_OpenSCManager))(lpMachine, lpDatabase, dwAccess);
+}
+
  /* exit() for Win32 is macro mapped (horrible, we agree) that allows us
   * to catch the non-zero conditions and inform the console process that
   * the application died, and hang on to the console a bit longer.
@@ -245,16 +282,54 @@ static void set_service_description(void
  if ((ChangeServiceConfig2) 
  (schSCManager = OpenSCManager(NULL, NULL, SC_MANAGER_CONNECT)))
  {
-SC_HANDLE schService = OpenService(schSCManager, mpm_service_name,
-   SERVICE_CHANGE_CONFIG);
+SC_HANDLE schService;
+
+#if APR_HAS_UNICODE_FS
+IF_WIN_OS_IS_UNICODE
+{
+schService = OpenServiceW(schSCManager,
+  (LPCWSTR)mpm_service_name_w,
+  SERVICE_CHANGE_CONFIG);
+}
+#endif /* APR_HAS_UNICODE_FS */
+#if APR_HAS_ANSI_FS
+ELSE_WIN_OS_IS_ANSI
+{
+schService = OpenService(schSCManager, mpm_service_name,
+ SERVICE_CHANGE_CONFIG);
+}
+#endif
  if (schService) {
If neither of these defines are set, then schService appears to be 
uninitialized

Re: svn commit: r1640823 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c

[Mike Rumph]

Hello Yann,

I would have thought that a MIN macro would already be defined somewhere.
If not, perhaps a more central location (some header file) could be 
chosen for it.


Thanks,

Mike

On 11/20/2014 1:38 PM, yla...@apache.org wrote:

Author: ylavic
Date: Thu Nov 20 21:38:53 2014
New Revision: 1640823

URL: http://svn.apache.org/r1640823
Log:
mod_reqtimeout: revert r1640758.
Unexpected functional change.

Modified:
 httpd/httpd/trunk/modules/filters/mod_reqtimeout.c

Modified: httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_reqtimeout.c?rev=1640823r1=1640822r2=1640823view=diff
==
--- httpd/httpd/trunk/modules/filters/mod_reqtimeout.c (original)
+++ httpd/httpd/trunk/modules/filters/mod_reqtimeout.c Thu Nov 20 21:38:53 2014
@@ -164,6 +164,7 @@ static apr_status_t brigade_append(apr_b
  }
  
  
+#define MIN(x,y) ((x)  (y) ? (x) : (y))

  static apr_status_t reqtimeout_filter(ap_filter_t *f,
apr_bucket_brigade *bb,
ap_input_mode_t mode,
@@ -227,10 +228,8 @@ static apr_status_t reqtimeout_filter(ap
  rv = apr_socket_timeout_get(ccfg-socket, saved_sock_timeout);
  AP_DEBUG_ASSERT(rv == APR_SUCCESS);
  
-if (time_left  saved_sock_timeout) {

-rv = apr_socket_timeout_set(ccfg-socket, time_left);
-AP_DEBUG_ASSERT(rv == APR_SUCCESS);
-}
+rv = apr_socket_timeout_set(ccfg-socket, MIN(time_left, 
saved_sock_timeout));
+AP_DEBUG_ASSERT(rv == APR_SUCCESS);
  
  if (mode == AP_MODE_GETLINE) {

  /*
@@ -299,10 +298,9 @@ static apr_status_t reqtimeout_filter(ap
  if (rv != APR_SUCCESS)
  break;
  
-if (time_left  saved_sock_timeout) {

-rv = apr_socket_timeout_set(ccfg-socket, time_left);
-AP_DEBUG_ASSERT(rv == APR_SUCCESS);
-}
+rv = apr_socket_timeout_set(ccfg-socket,
+   MIN(time_left, saved_sock_timeout));
+AP_DEBUG_ASSERT(rv == APR_SUCCESS);
  
  } while (1);
  
@@ -318,9 +316,7 @@ static apr_status_t reqtimeout_filter(ap

  }
  }
  
-if (saved_sock_timeout != time_left) {

-apr_socket_timeout_set(ccfg-socket, saved_sock_timeout);
-}
+apr_socket_timeout_set(ccfg-socket, saved_sock_timeout);
  
  out:

  if (APR_STATUS_IS_TIMEUP(rv)) {

Re: svn commit: r1627749 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/cache/cache_util.c

[Mike Rumph]

Hello Jim and Jan,

I am considering a proposal of backporting this fix to the 2.2 branch.
At first look, this fix doesn't apply to 2.2 code.
But I noticed that the pertinent code has been refactored between 2.2 
and 2.4.

The same problem exists in 2.2, but just in a different location.
In 2.2, the problem is in the store_headers function in 
modules/cache/mod_disk_cache.c.


Are either of you interested in working a patch for this?
Otherwise, I will look at it myself in a few days.

Thanks,

Mike Rumph

On 9/26/2014 4:00 AM, j...@apache.org wrote:

Author: jim
Date: Fri Sep 26 11:00:14 2014
New Revision: 1627749

URL: http://svn.apache.org/r1627749
Log:
Merge r1624234 from trunk:

SECURITY (CVE-2014-3581): Fix a mod_cache NULL pointer deference
in Content-Type handling.

mod_cache: Avoid a crash when Content-Type has an empty value. PR56924.

Submitted By: Mark Montague mark catseye.org
Reviewed By: Jan Kaluza

Submitted by: jkaluza
Reviewed/backported by: jim

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/modules/cache/cache_util.c

Propchange: httpd/httpd/branches/2.4.x/
--
   Merged /httpd/httpd/trunk:r1624234

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1627749r1=1627748r2=1627749view=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Fri Sep 26 11:00:14 2014
@@ -2,6 +2,10 @@
  
  Changes with Apache 2.4.11
  
+  *) SECURITY: CVE-2014-3581 (cve.mitre.org)

+ mod_cache: Avoid a crash when Content-Type has an empty value.
+ PR 56924.  [Mark Montague mark catseye.org, Jan Kaluza]
+
*) mod_cache: Avoid sending 304 responses during failed revalidations
   PR56881. [Eric Covener]
  


Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1627749r1=1627748r2=1627749view=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Fri Sep 26 11:00:14 2014
@@ -102,11 +102,6 @@ RELEASE SHOWSTOPPERS:
  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
  
-   * mod_cache: CVE-2014-3581 - Avoid a crash when Content-Type has an empty

- value. PR56924.
- trunk patch: http://svn.apache.org/r1624234
- 2.4.x patch: trunk works (modulo CHANGES)
- +1: jkaluza, jim, ylavic
  
  
  PATCHES PROPOSED TO BACKPORT FROM TRUNK:


Modified: httpd/httpd/branches/2.4.x/modules/cache/cache_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/cache/cache_util.c?rev=1627749r1=1627748r2=1627749view=diff
==
--- httpd/httpd/branches/2.4.x/modules/cache/cache_util.c (original)
+++ httpd/httpd/branches/2.4.x/modules/cache/cache_util.c Fri Sep 26 11:00:14 
2014
@@ -1258,8 +1258,10 @@ apr_table_t *cache_merge_headers_out(req
  
  if (r-content_type

   !apr_table_get(headers_out, Content-Type)) {
-apr_table_setn(headers_out, Content-Type,
-   ap_make_content_type(r, r-content_type));
+const char *ctype = ap_make_content_type(r, r-content_type);
+if (ctype) {
+apr_table_setn(headers_out, Content-Type, ctype);
+}
  }
  
  if (r-content_encoding

Re: svn commit: r1627749 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/cache/cache_util.c

[Mike Rumph]

In 2.2 code, this problem is actually in two places.
It is also in the store_headers function in modules/cache/mod_mem_cache.c.

On 10/14/2014 8:40 AM, Mike Rumph wrote:

Hello Jim and Jan,

I am considering a proposal of backporting this fix to the 2.2 branch.
At first look, this fix doesn't apply to 2.2 code.
But I noticed that the pertinent code has been refactored between 2.2 
and 2.4.

The same problem exists in 2.2, but just in a different location.
In 2.2, the problem is in the store_headers function in 
modules/cache/mod_disk_cache.c.


Are either of you interested in working a patch for this?
Otherwise, I will look at it myself in a few days.

Thanks,

Mike Rumph

On 9/26/2014 4:00 AM, j...@apache.org wrote:

Author: jim
Date: Fri Sep 26 11:00:14 2014
New Revision: 1627749

URL: http://svn.apache.org/r1627749
Log:
Merge r1624234 from trunk:

SECURITY (CVE-2014-3581): Fix a mod_cache NULL pointer deference
in Content-Type handling.

mod_cache: Avoid a crash when Content-Type has an empty value. PR56924.

Submitted By: Mark Montague mark catseye.org
Reviewed By: Jan Kaluza

Submitted by: jkaluza
Reviewed/backported by: jim

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/modules/cache/cache_util.c

Propchange: httpd/httpd/branches/2.4.x/
-- 


   Merged /httpd/httpd/trunk:r1624234

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1627749r1=1627748r2=1627749view=diff
== 


--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Fri Sep 26 11:00:14 2014
@@ -2,6 +2,10 @@
Changes with Apache 2.4.11
  +  *) SECURITY: CVE-2014-3581 (cve.mitre.org)
+ mod_cache: Avoid a crash when Content-Type has an empty value.
+ PR 56924.  [Mark Montague mark catseye.org, Jan Kaluza]
+
*) mod_cache: Avoid sending 304 responses during failed 
revalidations

   PR56881. [Eric Covener]

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1627749r1=1627748r2=1627749view=diff
== 


--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Fri Sep 26 11:00:14 2014
@@ -102,11 +102,6 @@ RELEASE SHOWSTOPPERS:
  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
  -   * mod_cache: CVE-2014-3581 - Avoid a crash when Content-Type 
has an empty

- value. PR56924.
- trunk patch: http://svn.apache.org/r1624234
- 2.4.x patch: trunk works (modulo CHANGES)
- +1: jkaluza, jim, ylavic
  PATCHES PROPOSED TO BACKPORT FROM TRUNK:

Modified: httpd/httpd/branches/2.4.x/modules/cache/cache_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/cache/cache_util.c?rev=1627749r1=1627748r2=1627749view=diff
== 


--- httpd/httpd/branches/2.4.x/modules/cache/cache_util.c (original)
+++ httpd/httpd/branches/2.4.x/modules/cache/cache_util.c Fri Sep 26 
11:00:14 2014

@@ -1258,8 +1258,10 @@ apr_table_t *cache_merge_headers_out(req
if (r-content_type
   !apr_table_get(headers_out, Content-Type)) {
-apr_table_setn(headers_out, Content-Type,
-   ap_make_content_type(r, r-content_type));
+const char *ctype = ap_make_content_type(r, r-content_type);
+if (ctype) {
+apr_table_setn(headers_out, Content-Type, ctype);
+}
  }
if (r-content_encoding

Re: svn commit: r1627749 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/cache/cache_util.c

[Mike Rumph]

Hello Eric,

Okay.  Thanks.
I must have missed that discussion.
I just now compared ap_make_content_type in both 2.2 and 2.4.
It looks like you are correct.
Some code to return NULL was added in 2.4.
So there is no need to check the return from ap_make_content_type for NULL.

Sorry for the noise.

Take care,

Mike

On 10/14/2014 10:03 AM, Eric Covener wrote:
I thought at the time, the discussion was that  ap_make_content_type 
in those releases never returned NULL.


On Tue, Oct 14, 2014 at 1:01 PM, Mike Rumph mike.ru...@oracle.com 
mailto:mike.ru...@oracle.com wrote:


In 2.2 code, this problem is actually in two places.
It is also in the store_headers function in
modules/cache/mod_mem_cache.c.


On 10/14/2014 8:40 AM, Mike Rumph wrote:

Hello Jim and Jan,

I am considering a proposal of backporting this fix to the 2.2
branch.
At first look, this fix doesn't apply to 2.2 code.
But I noticed that the pertinent code has been refactored
between 2.2 and 2.4.
The same problem exists in 2.2, but just in a different location.
In 2.2, the problem is in the store_headers function in
modules/cache/mod_disk_cache.c.

Are either of you interested in working a patch for this?
Otherwise, I will look at it myself in a few days.

Thanks,

Mike Rumph

On 9/26/2014 4:00 AM, j...@apache.org mailto:j...@apache.org
wrote:

Author: jim
Date: Fri Sep 26 11:00:14 2014
New Revision: 1627749

URL: http://svn.apache.org/r1627749
Log:
Merge r1624234 from trunk:

SECURITY (CVE-2014-3581): Fix a mod_cache NULL pointer
deference
in Content-Type handling.

mod_cache: Avoid a crash when Content-Type has an empty
value. PR56924.

Submitted By: Mark Montague mark catseye.org
http://catseye.org
Reviewed By: Jan Kaluza

Submitted by: jkaluza
Reviewed/backported by: jim

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/modules/cache/cache_util.c

Propchange: httpd/httpd/branches/2.4.x/

--

   Merged /httpd/httpd/trunk:r1624234

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL:

http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1627749r1=1627748r2=1627749view=diff

==

--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Fri Sep 26
11:00:14 2014
@@ -2,6 +2,10 @@
Changes with Apache 2.4.11
  +  *) SECURITY: CVE-2014-3581 (cve.mitre.org
http://cve.mitre.org)
+ mod_cache: Avoid a crash when Content-Type has an
empty value.
+ PR 56924.  [Mark Montague mark catseye.org
http://catseye.org, Jan Kaluza]
+
*) mod_cache: Avoid sending 304 responses during
failed revalidations
   PR56881. [Eric Covener]

Modified: httpd/httpd/branches/2.4.x/STATUS
URL:

http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1627749r1=1627748r2=1627749view=diff

==

--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Fri Sep 26 11:00:14 2014
@@ -102,11 +102,6 @@ RELEASE SHOWSTOPPERS:
  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
  -   * mod_cache: CVE-2014-3581 - Avoid a crash when
Content-Type has an empty
- value. PR56924.
- trunk patch: http://svn.apache.org/r1624234
- 2.4.x patch: trunk works (modulo CHANGES)
- +1: jkaluza, jim, ylavic
  PATCHES PROPOSED TO BACKPORT FROM TRUNK:

Modified:
httpd/httpd/branches/2.4.x/modules/cache/cache_util.c
URL:

http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/cache/cache_util.c?rev=1627749r1=1627748r2=1627749view=diff

==

--- httpd/httpd/branches/2.4.x/modules/cache/cache_util.c
(original)
+++ httpd/httpd/branches/2.4.x/modules/cache/cache_util.c

Re: svn commit: r1630406 - /httpd/httpd/branches/2.2.x/STATUS

[Mike Rumph]

This is so picky :).
s/accross/across/

On 10/9/2014 5:36 AM, yla...@apache.org wrote:

Author: ylavic
Date: Thu Oct  9 12:36:19 2014
New Revision: 1630406

URL: http://svn.apache.org/r1630406
Log:
Fix misspelling in changelog (including CHANGES for proposed patch).

Modified:
 httpd/httpd/branches/2.2.x/STATUS

Modified: httpd/httpd/branches/2.2.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=1630406r1=1630405r2=1630406view=diff
==
--- httpd/httpd/branches/2.2.x/STATUS (original)
+++ httpd/httpd/branches/2.2.x/STATUS Thu Oct  9 12:36:19 2014
@@ -111,7 +111,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
   2.2.x patch: 
http://people.apache.org/~wrowe/httpd-2.2-utf8-servicename.patch
   +1: wrowe
  
-   * mod_proxy: Reuse proxy workers's parameters and scores accross graceful

+   * mod_proxy: Reuse proxy workers' parameters and scores accross graceful
   restarts, even if new workers added, old ones removed, or the order
   changes.  [Jan Kaluza]
   2.2.x patch: 
http://people.apache.org/~ylavic/httpd-2.2.x-mod_proxy-balancer_graceful.patch

Re: svn commit: r1611252 - /httpd/httpd/trunk/include/util_varbuf.h

[Mike Rumph]

A few comments on typos below:

On 7/16/2014 10:34 PM, jaillet...@apache.org wrote:

Improve layout, add trailing '.' in function description, capitalize first 
letter of description, fix typo, turn \0 into \\0.
Move the detailled description after @defgroup so that it is taken into account.

s/detailled/detailed/

Modified:
 httpd/httpd/trunk/include/util_varbuf.h

Modified: httpd/httpd/trunk/include/util_varbuf.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/util_varbuf.h?rev=1611252r1=1611251r2=1611252view=diff
==
--- httpd/httpd/trunk/include/util_varbuf.h (original)
+++ httpd/httpd/trunk/include/util_varbuf.h Thu Jul 17 05:34:12 2014
@@ -42,87 +43,93 @@ extern C {

.

-/** initialize a resizable buffer. It is safe to re-initialize a prevously
- *  used ap_varbuf. The old buffer will be released when the corresponding
- *  pool is cleared. The buffer remains usable until the pool is cleared,
- *  even if the ap_varbuf was located on the stack and has gone out of scope.
- * @param pool the pool to allocate small buffers from and to register the
- *cleanup with
- * @param vb pointer to the ap_varbuf struct
- * @param init_size the initial size of the buffer (see ap_varbuf_grow() for 
details)
+/**
+ * Initialize a resizable buffer. It is safe to re-initialize a prevously

s/prevously/previously/

+ * used ap_varbuf. The old buffer will be released when the corresponding
+ * pool is cleared. The buffer remains usable until the pool is cleared,
+ * even if the ap_varbuf was located on the stack and has gone out of scope.
+ * @param   poolThe pool to allocate small buffers from and to register
+ *  the cleanup with
+ * @param   vb  Pointer to the ap_varbuf struct
+ * @param   init_size   The initial size of the buffer (see ap_varbuf_grow() 
for
+ *  details)
   */
  AP_DECLARE(void) ap_varbuf_init(apr_pool_t *pool, struct ap_varbuf *vb,
  apr_size_t init_size);

Re: Change of web site layout

[Mike Rumph]

Hello Greg,

I agree with your push towards a peaceful and constructive discussion on 
this.



Hello Daniel,

I applaud your efforts at introducing a new design to the Apache Http 
Server website.

As this is very different (though not radically so) from what was before,
it is very easy to criticize.
A change this big should be allowed time to breathe.

Is there a way that some of these webpage designs (yours, Tim's, etc.) 
can be added to a side page of the website for review.

So that the broader Apache HTTP Server community can have some input?


Hello Andre,

I also think all of your criticisms are important for the process.
Each of them should be considered.


Thanks to all,

Mike Rumph


On 6/16/2014 1:38 AM, Greg Stein wrote:
On Mon, Jun 16, 2014 at 3:00 AM, André Malo n...@perlig.de 
mailto:n...@perlig.de wrote:


* Daniel Gruno wrote:

...

I'm finding the back/forth here to be a bit more combative than maybe 
needed. Daniel: you asked for feedback. Andre could maybe be more 
constructive and appreciative of your work, but it *is* what you asked 
for.


Forward movement is good, and I greatly appreciate bringing in 
Bootstrap as a tool for making the site better looking, and more 
layout-responsive. Kudos.


Cheers,
-g

Re: svn commit: r1601943 - in /httpd/httpd/trunk: include/ap_mmn.h include/ap_mpm.h include/mpm_common.h modules/proxy/mod_proxy_wstunnel.c server/mpm/event/event.c server/mpm_common.c

[Mike Rumph]

On 6/11/2014 9:39 AM, taka...@apache.org wrote:

--- httpd/httpd/trunk/include/ap_mpm.h (original)
+++ httpd/httpd/trunk/include/ap_mpm.h Wed Jun 11 16:39:34 2014
@@ -198,6 +198,7 @@ AP_DECLARE(apr_status_t) ap_mpm_query(in
  /** @} */
  
  typedef void (ap_mpm_callback_fn_t)(void *baton);

+typedef void (ap_mpm_socket_callback_fn_t)(void *baton, const apr_pollfd_t 
*pdf);

Perhaps the intention was to name the second parameter as pfd.

Re: svn commit: r1599641 - in /httpd/httpd/trunk: include/ap_mmn.h include/util_time.h server/mpm/event/event.c server/mpm/eventopt/eventopt.c server/mpm/prefork/prefork.c server/mpm/worker/worker.c s

[Mike Rumph]

Hello Jim,

There is a small typo here.

s/many operationg systems/many operating systems/

Thanks,

Mike Rumph

On 6/3/2014 9:02 AM, j...@apache.org wrote:

Author: jim
Date: Tue Jun  3 16:02:44 2014
New Revision: 1599641

URL: http://svn.apache.org/r1599641
Log:
Break out common code to be share-able

Modified:
 httpd/httpd/trunk/include/ap_mmn.h
 httpd/httpd/trunk/include/util_time.h
 httpd/httpd/trunk/server/mpm/event/event.c
 httpd/httpd/trunk/server/mpm/eventopt/eventopt.c
 httpd/httpd/trunk/server/mpm/prefork/prefork.c
 httpd/httpd/trunk/server/mpm/worker/worker.c
 httpd/httpd/trunk/server/util_time.c

Modified: httpd/httpd/trunk/include/ap_mmn.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1599641r1=1599640r2=1599641view=diff
==
--- httpd/httpd/trunk/include/ap_mmn.h (original)
+++ httpd/httpd/trunk/include/ap_mmn.h Tue Jun  3 16:02:44 2014
@@ -455,6 +455,7 @@
   * 20140207.5 (2.5.0-dev)  Add ap_mpm_resume_suspended(), AP_MPMQ_CAN_SUSPEND 
to
   * ap_mpm_query(), and suspended_baton to conn_rec
   * 20140207.6 (2.5.0-dev)  Added ap_log_common().
+ * 20140207.7 (2.5.0-dev)  Added ap_force_set_tz().
   */
  
  #define MODULE_MAGIC_COOKIE 0x41503235UL /* AP25 */

@@ -462,7 +463,7 @@
  #ifndef MODULE_MAGIC_NUMBER_MAJOR
  #define MODULE_MAGIC_NUMBER_MAJOR 20140207
  #endif
-#define MODULE_MAGIC_NUMBER_MINOR 6  /* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 7  /* 0...n */
  
  /**

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

Modified: httpd/httpd/trunk/include/util_time.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/util_time.h?rev=1599641r1=1599640r2=1599641view=diff
==
--- httpd/httpd/trunk/include/util_time.h (original)
+++ httpd/httpd/trunk/include/util_time.h Tue Jun  3 16:02:44 2014
@@ -109,6 +109,12 @@ AP_DECLARE(apr_status_t) ap_recent_ctime
   */
  AP_DECLARE(apr_status_t) ap_recent_rfc822_date(char *date_str, apr_time_t t);
  
+/**

+ * Force an unset TZ to UTC
+ * @param p the pool to use
+ */
+AP_DECLARE(void) ap_force_set_tz(apr_pool_t *p);
+
  #ifdef __cplusplus
  }
  #endif

Modified: httpd/httpd/trunk/server/mpm/event/event.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1599641r1=1599640r2=1599641view=diff
==
--- httpd/httpd/trunk/server/mpm/event/event.c (original)
+++ httpd/httpd/trunk/server/mpm/event/event.c Tue Jun  3 16:02:44 2014
@@ -57,7 +57,6 @@
  #include apr_atomic.h
  #define APR_WANT_STRFUNC
  #include apr_want.h
-#include apr_env.h
  
  #include apr_version.h
  
@@ -97,6 +96,7 @@

  #include http_vhost.h
  #include unixd.h
  #include apr_skiplist.h
+#include util_time.h
  
  #include signal.h

  #include limits.h /* for INT_MAX */
@@ -2420,25 +2420,6 @@ static void join_start_thread(apr_thread
  }
  }
  
-static void force_set_tz(apr_pool_t *p) {

-/* If the TZ variable is unset, many operationg systems,
- * such as Linux, will at runtime read from /etc/localtime
- * and call fstat on it.
- *
- * By forcing the time zone to UTC if it is unset, we gain
- * about 2% in raw requests/second (since we format log files
- * in the local time, if present)
- *
- * For more info, see:
- *   http://www.gnu.org/s/hello/manual/libc/TZ-Variable.html
- */
-char *v = NULL;
-
-if (apr_env_get(v, TZ, p) != APR_SUCCESS) {
-apr_env_set(TZ, UTC+0, p);
-}
-}
-
  static void child_main(int child_num_arg)
  {
  apr_thread_t **threads;
@@ -3587,7 +3568,7 @@ static void event_hooks(apr_pool_t * p)
   */
  static const char *const aszSucc[] = { core.c, NULL };
  one_process = 0;
-force_set_tz(p);
+ap_force_set_tz(p);
  
  ap_hook_open_logs(event_open_logs, NULL, aszSucc, APR_HOOK_REALLY_FIRST);

  /* we need to set the MPM state before other pre-config hooks use MPM 
query

Modified: httpd/httpd/trunk/server/mpm/eventopt/eventopt.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/eventopt/eventopt.c?rev=1599641r1=1599640r2=1599641view=diff
==
--- httpd/httpd/trunk/server/mpm/eventopt/eventopt.c (original)
+++ httpd/httpd/trunk/server/mpm/eventopt/eventopt.c Tue Jun  3 16:02:44 2014
@@ -57,7 +57,6 @@
  #include apr_atomic.h
  #define APR_WANT_STRFUNC
  #include apr_want.h
-#include apr_env.h
  
  #if APR_HAVE_UNISTD_H

  #include unistd.h
@@ -91,6 +90,7 @@
  #include mpm_default.h
  #include http_vhost.h
  #include unixd.h
+#include util_time.h
  
  #include signal.h

  #include limits.h /* for INT_MAX */
@@ -2231,25 +2231,6 @@ static void join_start_thread(apr_thread

Re: svn commit: r1594301 - in /httpd/httpd/trunk/server/mpm: event/event.c eventopt/eventopt.c worker/worker.c

[Mike Rumph]

s/appropiate/appropriate/

This could also be fixed in APR, if someone with APR commit access has a 
few idle minutes.


Thanks,

Mike Rumph


On 5/13/2014 10:50 AM, mru...@apache.org wrote:

Author: mrumph
Date: Tue May 13 17:50:39 2014
New Revision: 1594301

URL: http://svn.apache.org/r1594301
Log:
Fix some comment typos

Modified:
 httpd/httpd/trunk/server/mpm/event/event.c
 httpd/httpd/trunk/server/mpm/eventopt/eventopt.c
 httpd/httpd/trunk/server/mpm/worker/worker.c

Modified: httpd/httpd/trunk/server/mpm/event/event.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1594301r1=1594300r2=1594301view=diff
==
--- httpd/httpd/trunk/server/mpm/event/event.c (original)
+++ httpd/httpd/trunk/server/mpm/event/event.c Tue May 13 17:50:39 2014
@@ -664,7 +664,7 @@ static apr_status_t decrement_connection
   * Previously this was initiated in sig_term() and restart() signal handlers,
   * but we want to be able to start a shutdown/restart from other sources --
   * e.g. on Win32, from the service manager. Now the service manager can
- * call ap_start_shutdown() or ap_start_restart() as appropiate.  Note that
+ * call ap_start_shutdown() or ap_start_restart() as appropriate.  Note that
   * these functions can also be called by the child processes, since global
   * variables are no longer used to pass on the required action to the parent.
   *

Modified: httpd/httpd/trunk/server/mpm/eventopt/eventopt.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/eventopt/eventopt.c?rev=1594301r1=1594300r2=1594301view=diff
==
--- httpd/httpd/trunk/server/mpm/eventopt/eventopt.c (original)
+++ httpd/httpd/trunk/server/mpm/eventopt/eventopt.c Tue May 13 17:50:39 2014
@@ -651,7 +651,7 @@ static apr_status_t decrement_connection
   * Previously this was initiated in sig_term() and restart() signal handlers,
   * but we want to be able to start a shutdown/restart from other sources --
   * e.g. on Win32, from the service manager. Now the service manager can
- * call ap_start_shutdown() or ap_start_restart() as appropiate.  Note that
+ * call ap_start_shutdown() or ap_start_restart() as appropriate.  Note that
   * these functions can also be called by the child processes, since global
   * variables are no longer used to pass on the required action to the parent.
   *

Modified: httpd/httpd/trunk/server/mpm/worker/worker.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/worker/worker.c?rev=1594301r1=1594300r2=1594301view=diff
==
--- httpd/httpd/trunk/server/mpm/worker/worker.c (original)
+++ httpd/httpd/trunk/server/mpm/worker/worker.c Tue May 13 17:50:39 2014
@@ -457,7 +457,7 @@ static int volatile restart_pending;
   * Previously this was initiated in sig_term() and restart() signal handlers,
   * but we want to be able to start a shutdown/restart from other sources --
   * e.g. on Win32, from the service manager. Now the service manager can
- * call ap_start_shutdown() or ap_start_restart() as appropiate.  Note that
+ * call ap_start_shutdown() or ap_start_restart() as appropriate.  Note that
   * these functions can also be called by the child processes, since global
   * variables are no longer used to pass on the required action to the parent.
   *

Re: svn commit: r1588135 - in /httpd/httpd/branches/2.4.x/docs/manual/mod: mod_logio.html.en mod_logio.xml

[Mike Rumph]

Grammar corrections below.

On 4/16/2014 10:38 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Thu Apr 17 05:38:49 2014
New Revision: 1588135

URL: http://svn.apache.org/r1588135
Log:
s/two/three/

Modified:
 httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.html.en
 httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.html.en
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.html.en?rev=1588135r1=1588134r2=1588135view=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.html.en (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.html.en Thu Apr 17 
05:38:49 2014
@@ -68,7 +68,7 @@
  h2a name=formats id=formatsCustom Log Formats/a/h2
  
  
-pThis modules adds two new logging directives. The characteristics of the

+pThis modules adds three new logging directives. The characteristics of 
the

 s/This modules/This module/

  request itself are logged by placing code%/code directives in
  the format string, which are replaced in the log file by the values as
  follows:/p

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml?rev=1588135r1=1588134r2=1588135view=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml Thu Apr 17 
05:38:49 2014
@@ -52,7 +52,7 @@
  section id=formats
  titleCustom Log Formats/title
  
-pThis modules adds two new logging directives. The characteristics of the

+pThis modules adds three new logging directives. The characteristics of 
the

 s/This modules/This module/

  request itself are logged by placing code%/code directives in
  the format string, which are replaced in the log file by the values as
  follows:/p

Re: Configuration error handling after httpd restart

[Mike Rumph]

Hello Jim,

Thanks for taking a look at this and providing a patch for case 2 
(duplicate Listen directives).

I will need to evaluate this patch in more detail.
Your approach of simply ignoring duplicate Listen directives with a 
warning seems reasonable.

At least in the simple case that I listed.
But it does cause a change in behavior for apachectl -k start as well 
as apachectl -k restart.

Is this acceptable?
The same approach could be taken for case 1.
If there is an unknown directive in the config file, simply ignore it 
with a warning.

Does anyone else have an opinion on this?

There are also underlying issues that are bypassed by your fix.
Other more complicated test cases may uncover these again.
I hope to have some time to investigate these issues and do further 
negative testing.


Thanks,

Mike


On 4/11/2014 10:43 AM, Jim Riggs wrote:

On 27 Mar 2014, at 14:16, Mike Rumph mike.ru...@oracle.com wrote:


Hello all,

I have been doing some testing on the results of httpd restart with 
configuration errors.
This gave me some interesting results.

For these tests I build httpd trunk with APR trunk on Linux using the following 
configure:
$ ./configure --prefix=/home/mrumph/apache25 --with-included-apr 
--with-mpm=worker --enable-mpms-shared='worker'

Modify the default httpd.conf to include the following line:
Listen localhost:8080

Start the httpd server and verify the process information.
$ bin/apachectl -k start
$ ps -ef | grep -i httpd

Now restart httpd from this starting point with the following configuration 
error cases:

Case 1:  An unknown directive.
Add the following line to the httpd.conf file.
Xyzzy

bin/apachectl -k restart
   - Returns with exit code 1 and following error message in stderr:
AH00526: Syntax error on line 198 of /home/mrumph/apache25/conf/httpd.conf:
Invalid command 'Xyzzy', perhaps misspelled or defined by a module not included 
in the server configuration
httpd: abnormal exit 1

$ ps -ef | grep -i httpd
   - The httpd server was not stopped and all of the previous processes remain.
   - And the logs/httpd.pid file remains intact.

$ tail logs/error_log
   - No error message logged.

Case 2:  A duplicate Listen directive.
Duplicate the Listen directive in the httpd.conf file.
Listen localhost:8080
Listen localhost:8080

$ bin/apachectl -k restart
   - Returns with exit code 0 and no error message in stderr.
   - So the httpd server appears to be working at this point.
   - (But appearances are deceiving.)

$ ps -ef | grep -i httpd
   - All of the httpd processes have stopped.
   - But the logs/httpd.pid file remains intact.

$ tail logs/error_log
[Thu Mar 27 11:26:22.836887 2014] [mpm_worker:notice] [pid 2677:tid 
47577479346656] AH00298: SIGHUP received.  Attempting to restart
(98)Address already in use: AH00072: make_sock: could not bind to address 
127.0.0.1:8080
[Thu Mar 27 11:26:22.844003 2014] [mpm_worker:alert] [pid 2677:tid 
47577479346656] no listening sockets available, shutting down
[Thu Mar 27 11:26:22.844031 2014] [core:emerg] [pid 2677:tid 47577479346656] 
AH00019: Unable to open logs, exiting


This was httpd trunk, but similar results are seen with httpd 2.2.22, 2.2-HEAD 
and 2.4.6.


Before working on this as a bug, I am trying to understand what should be the 
correct behavior.
I think case 1 is working correctly.
But case 2 doesn't seem quite right.
First of all, it doesn't seem correct to have an httpd.pid file when all of the 
httpd processes have vanished.
Secondly, it would be nice to see an error code from the apachectl -k restart.
(But this is probably due to a different processing phase in the validation for 
both of the cases.)
It is also a little strange to see a message Unable to open logs in the log.

Does anyone have some opinions what the correct behavior should be for these 
cases.

If there are some actual bugs here, I have some time available to work on them.



Check out the attached patch to ignore duplicate Listen directives.

Re: svn commit: r1585157 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_rewrite.xml docs/manual/rewrite/flags.xml modules/mappers/mod_rewrite.c

[Mike Rumph]

Small typo fix below:
On 4/5/2014 11:40 AM, cove...@apache.org wrote:

Author: covener
Date: Sat Apr  5 18:40:36 2014
New Revision: 1585157

URL: http://svn.apache.org/r1585157
Log:
add BNP flag to give control to the user on whether a space ' ' in
an escaped backrefernece is decoded to a + (default) or %20. Useful
if your backreference isn't going into the query string.


Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml
 httpd/httpd/trunk/docs/manual/rewrite/flags.xml
 httpd/httpd/trunk/modules/mappers/mod_rewrite.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1585157r1=1585156r2=1585157view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Sat Apr  5 18:40:36 2014
@@ -1,6 +1,10 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.0
  
+  *) mod_rewrite: Add 'BNF' (backreferences-no-plus) flag to RewriteRule to

s/BNF/BNP/

+ allow spaces in backreferences to be encoded as %20 instead of '+'.
+ [Eric Covener]
+
*) mod_ssl: bring SNI behavior into better conformance with RFC 6066:
   no longer send warning-level unrecognized_name(112) alerts,
   and limit startup warnings to cases where an OpenSSL version

Modified: httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml?rev=1585157r1=1585156r2=1585157view=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml Sat Apr  5 18:40:36 2014
@@ -1189,6 +1189,14 @@ cannot use code$N/code in the substi
  href=../rewrite/flags.html#flag_bdetails .../a/em/td
  /tr
  tr
+tdbackrefnoplus|BNP/td
+tdIf backreferences are being escaped, spaces should be escaped to
+%20 instead of +. Useful when the backreference will be used in the
+path component rather than the query string.ema
+href=../rewrite/flags.html#flag_bnpdetails .../a/em/td
+/tr
+
+tr
  tdchain|C/td
  tdRule is chained to the following rule. If the rule fails,
  the rule(s) chained to it will be skipped. ema

Modified: httpd/httpd/trunk/docs/manual/rewrite/flags.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/rewrite/flags.xml?rev=1585157r1=1585156r2=1585157view=diff
==
--- httpd/httpd/trunk/docs/manual/rewrite/flags.xml (original)
+++ httpd/httpd/trunk/docs/manual/rewrite/flags.xml Sat Apr  5 18:40:36 2014
@@ -71,6 +71,12 @@ characters before applying the transform
  pIn 2.4.10 and later, you can limit the escaping to specific characters
  in backreferences by listing them: code[B=#?;]/code /p
  
+section id=flag_bnptitleBNP|backrefnoplus (don't escape space to +)/title

+pThe [BNP] flag instructs directive
+module=mod_rewriteRewriteRule/directive to escape the space character
+in a backreference to %20 rather than '+'. Useful when the backreference
+will be used in the path component rather than the query string.
+
  pcodemod_rewrite/code has to unescape URLs before mapping them,
  so backreferences are unescaped at the time they are applied.
  Using the B flag, non-alphanumeric characters in backreferences

Modified: httpd/httpd/trunk/modules/mappers/mod_rewrite.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_rewrite.c?rev=1585157r1=1585156r2=1585157view=diff
==
--- httpd/httpd/trunk/modules/mappers/mod_rewrite.c (original)
+++ httpd/httpd/trunk/modules/mappers/mod_rewrite.c Sat Apr  5 18:40:36 2014
@@ -170,6 +170,7 @@ static const char* really_last_key = re
  #define RULEFLAG_DISCARDPATHINFO115
  #define RULEFLAG_QSDISCARD  116
  #define RULEFLAG_END117
+#define RULEFLAG_ESCAPENOPLUS   118
  
  /* return code of the rewrite rule

   * the result may be escaped - or not
@@ -420,7 +421,7 @@ static const char *rewritemap_mutex_type
  /* Optional functions imported from mod_ssl when loaded: */
  static APR_OPTIONAL_FN_TYPE(ssl_var_lookup) *rewrite_ssl_lookup = NULL;
  static APR_OPTIONAL_FN_TYPE(ssl_is_https) *rewrite_is_https = NULL;
-static char *escape_uri(apr_pool_t *p, const char *path, const char *escapeme);
+static char *escape_backref(apr_pool_t *p, const char *path, const char 
*escapeme, int noplus);
  
  /*

   * +---+
@@ -629,10 +630,10 @@ static APR_INLINE unsigned char *c2x(uns
  }
  
  /*

- * Escapes a uri in a similar way as php's urlencode does.
+ * Escapes a backreference in a similar way as 

Re: stop copying footers to r-headers_in?

[Mike Rumph]

Hello Yann,

Comment included below.

Thanks,

Mike Rumph
On 4/1/2014 11:00 AM, Yann Ylavic wrote:


Index: modules/examples/mod_example_hooks.c
===
--- modules/examples/mod_example_hooks.c(revision 1583714)
+++ modules/examples/mod_example_hooks.c(working copy)
@@ -1227,7 +1227,23 @@ static int x_header_parser(request_rec *r)
  return DECLINED;
  }

+/*
+ * this routine gives our module another chance to examine the request
+ * trailers and to take special action.
+ *
+ * This is a RUN_ALL hook.
+ */
+static int x_trailer_parser(request_rec *r)
+{
+/*
+ * We don't actually *do* anything here, except note the fact that we were
+ * called.
+ */
+trace_request(r, x_trailer_parser());
+return DECLINED;
+}

+
  /*
   * This routine is called to check for any module-specific restrictions placed
   * upon the requested resource.  (See the mod_access_compat module for an
@@ -1469,6 +1485,7 @@ static void x_register_hooks(apr_pool_t *p)
  ap_hook_translate_name(x_translate_name, NULL, NULL, APR_HOOK_MIDDLE);
  ap_hook_map_to_storage(x_map_to_storage, NULL,NULL, APR_HOOK_MIDDLE);
  ap_hook_header_parser(x_header_parser, NULL, NULL, APR_HOOK_MIDDLE);
+ap_hook_header_parser(x_trailer_parser, NULL, NULL, APR_HOOK_MIDDLE);

Should this be ap_hook_trailer_parser?

  ap_hook_fixups(x_fixups, NULL, NULL, APR_HOOK_MIDDLE);
  ap_hook_type_checker(x_type_checker, NULL, NULL, APR_HOOK_MIDDLE);
  ap_hook_check_access(x_check_access, NULL, NULL, APR_HOOK_MIDDLE,

Configuration error handling after httpd restart

[Mike Rumph]

Hello all,

I have been doing some testing on the results of httpd restart with 
configuration errors.

This gave me some interesting results.

For these tests I build httpd trunk with APR trunk on Linux using the 
following configure:
$ ./configure --prefix=/home/mrumph/apache25 --with-included-apr 
--with-mpm=worker --enable-mpms-shared='worker'


Modify the default httpd.conf to include the following line:
Listen localhost:8080

Start the httpd server and verify the process information.
$ bin/apachectl -k start
$ ps -ef | grep -i httpd

Now restart httpd from this starting point with the following 
configuration error cases:


Case 1:  An unknown directive.
Add the following line to the httpd.conf file.
Xyzzy

bin/apachectl -k restart
   - Returns with exit code 1 and following error message in stderr:
AH00526: Syntax error on line 198 of /home/mrumph/apache25/conf/httpd.conf:
Invalid command 'Xyzzy', perhaps misspelled or defined by a module not 
included in the server configuration

httpd: abnormal exit 1

$ ps -ef | grep -i httpd
   - The httpd server was not stopped and all of the previous processes 
remain.

   - And the logs/httpd.pid file remains intact.

$ tail logs/error_log
   - No error message logged.

Case 2:  A duplicate Listen directive.
Duplicate the Listen directive in the httpd.conf file.
Listen localhost:8080
Listen localhost:8080

$ bin/apachectl -k restart
   - Returns with exit code 0 and no error message in stderr.
   - So the httpd server appears to be working at this point.
   - (But appearances are deceiving.)

$ ps -ef | grep -i httpd
   - All of the httpd processes have stopped.
   - But the logs/httpd.pid file remains intact.

$ tail logs/error_log
[Thu Mar 27 11:26:22.836887 2014] [mpm_worker:notice] [pid 2677:tid 
47577479346656] AH00298: SIGHUP received.  Attempting to restart
(98)Address already in use: AH00072: make_sock: could not bind to 
address 127.0.0.1:8080
[Thu Mar 27 11:26:22.844003 2014] [mpm_worker:alert] [pid 2677:tid 
47577479346656] no listening sockets available, shutting down
[Thu Mar 27 11:26:22.844031 2014] [core:emerg] [pid 2677:tid 
47577479346656] AH00019: Unable to open logs, exiting



This was httpd trunk, but similar results are seen with httpd 2.2.22, 
2.2-HEAD and 2.4.6.



Before working on this as a bug, I am trying to understand what should 
be the correct behavior.

I think case 1 is working correctly.
But case 2 doesn't seem quite right.
First of all, it doesn't seem correct to have an httpd.pid file when all 
of the httpd processes have vanished.
Secondly, it would be nice to see an error code from the apachectl -k 
restart.
(But this is probably due to a different processing phase in the 
validation for both of the cases.)
It is also a little strange to see a message Unable to open logs in 
the log.


Does anyone have some opinions what the correct behavior should be for 
these cases.


If there are some actual bugs here, I have some time available to work 
on them.


Thanks,

Mike Rumph

Re: svn commit: r1574518 - /httpd/httpd/trunk/modules/loggers/mod_log_config.c

[Mike Rumph]

Hello Jim,

I see a style difference in the change below compare to the lines just 
above it.

How to test a value after an assignment.
In the while statement the value is tested implicitly.
In the if statement the value is explicitly compared against NULL.
Usually the second way is chosen to avoid the appearance of an obvious 
mistake (= versus ==).
Especially when code is this close together, I would think that we would 
want to use a consistent convention.
Or maybe you just don't want to change the style of existing code at the 
same time as adding new code, correct?


Thanks,

Mike

On 3/5/2014 7:00 AM, j...@apache.org wrote:

Author: jim
Date: Wed Mar  5 15:00:56 2014
New Revision: 1574518

URL: http://svn.apache.org/r1574518
Log:
ensure cookies have name/value

Modified:
 httpd/httpd/trunk/modules/loggers/mod_log_config.c

Modified: httpd/httpd/trunk/modules/loggers/mod_log_config.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/loggers/mod_log_config.c?rev=1574518r1=1574517r2=1574518view=diff
==
--- httpd/httpd/trunk/modules/loggers/mod_log_config.c (original)
+++ httpd/httpd/trunk/modules/loggers/mod_log_config.c Wed Mar  5 15:00:56 2014
@@ -542,8 +542,9 @@ static const char *log_cookie(request_re
  char *cookies = apr_pstrdup(r-pool, cookies_entry);
  
  while ((cookie = apr_strtok(cookies, ;, last1))) {

-char *name = apr_strtok(cookie, =, last2);
-if (name) {
+char *name;
+if (strchr(cookie, '=') 
+   (name = apr_strtok(cookie, =, last2)) != NULL) {
  char *value = name + strlen(name) + 1;
  apr_collapse_spaces(name, name);
  

Re: Review of mod_proxy_http proposal for httpd 2.4.8

[Mike Rumph]

Hello Yann,

Thanks for your explanation.
Okay, that clears it up for me.

On 2/27/2014 1:36 AM, Yann Ylavic wrote:

Hello Mike
,

thanks for looking at this.


On Wed, Feb 26, 2014 at 8:11 PM, Mike Rumph mike.ru...@oracle.com 
mailto:mike.ru...@oracle.com wrote:


I am trying to review the following mod_proxy_http proposal for
httpd 2.4.8:

   * mod_proxy_http: Log an error when reading the request body fails.
 trunk patch: http://svn.apache.org/r1570598
 2.4.x patch:  trunk works modulo next_number
 +1: ylavic, jim

I have one question at this point.
r1570598 is listed as a follow up to http://svn.apache.org/r1538776 .


But r1538776 does not appear to have been backported to or
proposed for httpd 2.4.x.


The backport is http://svn.apache.org/r1570324.
ap_http_filter() in trunk and 2.4 are quite different and need a 
different patch regarding incomplete body detection.


-

http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/chunk_filter.c?r1=1538776r2=1538775pathrev=1538776



This one does not need to be backported, for now, since 
https://svn.apache.org/r1480058 isn't (cf. -1 vote in 2.4.x/STATUS).


-

http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http/chunk_filter.c?view=markup



I did mean the link above.
It shows that the patch to chunk_filter.c in r1538776 was not applied to 
2.4.x.

But your explanation below makes sense.

Thanks,

Mike Rumph
Do you mean 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?r1=1538776r2=1538775pathrev=1538776 
?



Do these two patches need to stay together (atomic)?


mod_proxy in 2.4.x always uses HTTP_BAD_GATEWAY as error bucket when 
response (body) forwarding fails.
The ap_http_outerror_filter() and ap_http_chunk_filter() output 
filters only need to detect that bucket to do the right thing.

Hence 2.4.x needs no fix there.

In trunk though, HTTP_GATEWAY_TIMEOUT is in the place and must be 
handled like HTTP_BAD_GATEWAY.
But this is not limited to the APR_INCOMPLETE error introduced by this 
patch, maybe that could have been commited separately.


Regards,
Yann.

Review of mod_proxy_http proposal for httpd 2.4.8

[Mike Rumph]

Hello Yann,

I am trying to review the following mod_proxy_http proposal for httpd 2.4.8:

   * mod_proxy_http: Log an error when reading the request body fails.
 trunk patch: http://svn.apache.org/r1570598
 2.4.x patch:  trunk works modulo next_number
 +1: ylavic, jim

I have one question at this point.
r1570598 is listed as a follow up to http://svn.apache.org/r1538776 .

But r1538776 does not appear to have been backported to or proposed for 
httpd 2.4.x.
- 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/chunk_filter.c?r1=1538776r2=1538775pathrev=1538776 

- 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http/chunk_filter.c?view=markup


Do these two patches need to stay together (atomic)?

Thanks,

Mike Rumph

Re: Welcome to Mike Rumph and Yann Ylavic!

[Mike Rumph]

Hello all,

Thanks for the welcome!
I look forward to working with all of you towards an even better Apache 
HTTP Server.


See you in Denver,

Mike Rumph

On 2/17/2014 9:28 AM, Daniel Gruno wrote:

On 02/17/2014 06:26 PM, Eric Covener wrote:

Mike Rumph and Yann Ylavic have recently joined us as committers.

Welcome!

(We don't usually send this welcome e-mail to dev@, but I think it's a
good thing to do).


Welcome aboard, and well deserved!!

With regards,
Daniel.

Re: svn commit: r1569108 - /httpd/httpd/branches/2.4.x/STATUS

[Mike Rumph]

Hello Jim,

I voted for this change for backport to 2.4.8.

The fix looks solid to me at this time.

But I do have a couple of questions/ideas for the future.

1)  proxy_schemes_t in modules/proxy/proxy_util.c and schemes_t in 
apr-util/uri/apr_uri.c

 are identical in structure and field names.
 Could this be pulled to apr-util/include/apr_util.h in future 
releases of apr-util?


2)  Could mod_proxy_wstunnel.c benefit from a similar change as this  
fix does for mod_proxy_http.c?


Thanks,

Mike Rumph


On 2/17/2014 12:42 PM, mru...@apache.org wrote:

Author: mrumph
Date: Mon Feb 17 20:42:15 2014
New Revision: 1569108

URL: http://svn.apache.org/r1569108
Log:
Vote for mod_proxy fix.

Modified:
 httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1569108r1=1569107r2=1569108view=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon Feb 17 20:42:15 2014
@@ -98,6 +98,14 @@ RELEASE SHOWSTOPPERS:
  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
  
+  * mod_proxy: Use consistent canon formats for http, ajp and fcgi (if provided

+port is the default port, don't add to canon URI). Ensures that ajp and
+fcgi uses the defined workers and not the default generic reverse proxy
+worker.
+trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1542562
+2.4.x patch: http://people.apache.org/~jim/patches/proxy-port-scheme.patch
++1: jim, druggeri, mrumph
+
  
  PATCHES PROPOSED TO BACKPORT FROM TRUNK:

[ New proposals should be added at the end of the list ]
@@ -114,20 +122,11 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
   without mod_request and mod_session present would cause the very
   same failure. Would a warning in the release notes be good 
enough?
  
-  * mod_proxy: Use consistent canon formats for http, ajp and fcgi (if provided

-port is the default port, don't add to canon URI). Ensures that ajp and
-fcgi uses the defined workers and not the default generic reverse proxy
-worker.
-trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1542562
-2.4.x patch: http://people.apache.org/~jim/patches/proxy-port-scheme.patch
-+1: jim, druggeri
-
* prefork: PR: 54852. Only use a dummy_connection for idle processes
  trunk patch: http://svn.apache.org/viewvc?view=revisionrevision=1542379
  2.4.x patch: trunk patch works mod CHANGES
  +1: jim, covener
  
-

* FreeBSD: Disable IPv4-mapped listening sockets by default for versions
  5+ instead of just for FreeBSD 5. PR 53824.
  trunk patch: http://svn.apache.org/r1551685

Re: svn commit: r1569108 - /httpd/httpd/branches/2.4.x/STATUS

[Mike Rumph]

On 2/17/2014 1:11 PM, Mike Rumph wrote:

Hello Jim,

I voted for this change for backport to 2.4.8.

The fix looks solid to me at this time.

But I do have a couple of questions/ideas for the future.

1)  proxy_schemes_t in modules/proxy/proxy_util.c and schemes_t in 
apr-util/uri/apr_uri.c

 are identical in structure and field names.
 Could this be pulled to apr-util/include/apr_util.h in future 
releases of apr-util?

I meant apr-util/include/apr_uri.h


2)  Could mod_proxy_wstunnel.c benefit from a similar change as this  
fix does for mod_proxy_http.c?


Thanks,

Mike Rumph


On 2/17/2014 12:42 PM, mru...@apache.org wrote:

Author: mrumph
Date: Mon Feb 17 20:42:15 2014
New Revision: 1569108

URL: http://svn.apache.org/r1569108
Log:
Vote for mod_proxy fix.

Modified:
 httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1569108r1=1569107r2=1569108view=diff
== 


--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon Feb 17 20:42:15 2014
@@ -98,6 +98,14 @@ RELEASE SHOWSTOPPERS:
  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
  +  * mod_proxy: Use consistent canon formats for http, ajp and fcgi 
(if provided
+port is the default port, don't add to canon URI). Ensures that 
ajp and
+fcgi uses the defined workers and not the default generic 
reverse proxy

+worker.
+trunk patch: 
https://svn.apache.org/viewvc?view=revisionrevision=1542562
+2.4.x patch: 
http://people.apache.org/~jim/patches/proxy-port-scheme.patch

++1: jim, druggeri, mrumph
+
PATCHES PROPOSED TO BACKPORT FROM TRUNK:
[ New proposals should be added at the end of the list ]
@@ -114,20 +122,11 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
   without mod_request and mod_session present would 
cause the very
   same failure. Would a warning in the release notes be 
good enough?
  -  * mod_proxy: Use consistent canon formats for http, ajp and fcgi 
(if provided
-port is the default port, don't add to canon URI). Ensures that 
ajp and
-fcgi uses the defined workers and not the default generic 
reverse proxy

-worker.
-trunk patch: 
https://svn.apache.org/viewvc?view=revisionrevision=1542562
-2.4.x patch: 
http://people.apache.org/~jim/patches/proxy-port-scheme.patch

-+1: jim, druggeri
-
* prefork: PR: 54852. Only use a dummy_connection for idle processes
  trunk patch: 
http://svn.apache.org/viewvc?view=revisionrevision=1542379

  2.4.x patch: trunk patch works mod CHANGES
  +1: jim, covener
  -
* FreeBSD: Disable IPv4-mapped listening sockets by default for 
versions

  5+ instead of just for FreeBSD 5. PR 53824.
  trunk patch: http://svn.apache.org/r1551685

Re: svn commit: r1565717 - /httpd/httpd/trunk/server/core.c

[Mike Rumph]

Hello Jim,

What is the purpose of the extra / on line 1?

Thanks,

Mike Rumph
On 2/7/2014 8:44 AM, j...@apache.org wrote:

Author: jim
Date: Fri Feb  7 16:44:57 2014
New Revision: 1565717

URL: http://svn.apache.org/r1565717
Log:
Oops... missed this when I switched slaves to their
own struct (for ease of use w/ arrays)

Modified:
 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=1565717r1=1565716r2=1565717view=diff
==
--- httpd/httpd/trunk/server/core.c (original)
+++ httpd/httpd/trunk/server/core.c Fri Feb  7 16:44:57 2014
@@ -1,4 +1,4 @@
-/* Licensed to the Apache Software Foundation (ASF) under one or more
+//* 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
@@ -4848,7 +4848,7 @@ static conn_rec *core_create_conn(apr_po
  
  c-conn_config = ap_create_conn_config(c-pool);

  c-notes = apr_table_make(c-pool, 5);
-c-slaves = apr_array_make(c-pool, 20, sizeof(conn_rec *));
+c-slaves = apr_array_make(c-pool, 20, sizeof(conn_slave_rec *));
  
  
  if ((rv = apr_socket_addr_get(c-local_addr, APR_LOCAL, csd))

Re: svn commit: r1563894 - in /httpd/httpd/trunk/modules/ssl: ssl_engine_kernel.c ssl_private.h

[Mike Rumph]

Hello Jeff,

s/limitiations/limitations/

Thanks,

Mike Rumph

On 2/3/2014 5:50 AM, traw...@apache.org wrote:

Author: trawick
Date: Mon Feb  3 13:50:14 2014
New Revision: 1563894

URL: http://svn.apache.org/r1563894
Log:
fix a few spelling errors

Modified:
 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_kernel.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1563894r1=1563893r2=1563894view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Mon Feb  3 13:50:14 2014
@@ -176,8 +176,8 @@ int ssl_hook_ReadReq(request_rec *r)
   * cause us to end up in a different virtual host as the one that
   * was used for the handshake causing different SSL parameters to
   * be applied as SSLProtocol, SSLCACertificateFile/Path and
- * SSLCADNRequestFile/Path cannot be renegotioated (SSLCA* due
- * to current limitiations in Openssl, see
+ * SSLCADNRequestFile/Path cannot be renegotiated (SSLCA* due
+ * to current limitiations in OpenSSL, see
   * 
http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3c48592955.2090...@velox.ch%3E
   * and
   * 
http://mail-archives.apache.org/mod_mbox/httpd-dev/201312.mbox/%3CCAKQ1sVNpOrdiBm-UPw1hEdSN7YQXRRjeaT-MCWbW_7mN%3DuFiOw%40mail.gmail.com%3E
@@ -207,7 +207,7 @@ int ssl_hook_ReadReq(request_rec *r)
  /*
   * We are using a name based configuration here, but no hostname 
was
   * provided via SNI. Don't allow that if are requested to do 
strict
- * checking. Check wether this strict checking was setup either in 
the
+ * checking. Check whether this strict checking was setup either 
in the
   * server config we used for handshaking or in our current server.
   * This should avoid insecure configuration by accident.
   */
@@ -1904,7 +1904,7 @@ void ssl_callback_Info(const SSL *ssl, i
  }
  }
  /* If the first handshake is complete, change state to reject any
- * subsequent client-initated renegotiation. */
+ * subsequent client-initiated renegotiation. */
  else if ((where  SSL_CB_HANDSHAKE_DONE)  scr-reneg_state == 
RENEG_INIT) {
  scr-reneg_state = RENEG_REJECT;
  }
@@ -2033,7 +2033,7 @@ static int ssl_find_vhost(void *serverna
   * vhost we have just switched to. Again, we have to make sure
   * that we're not overwriting a session id context which was
   * possibly set in ssl_hook_Access(), before triggering
- * a renegotation.
+ * a renegotiation.
   */
  if (SSL_num_renegotiations(ssl) == 0) {
  unsigned char *sid_ctx =

Modified: httpd/httpd/trunk/modules/ssl/ssl_private.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?rev=1563894r1=1563893r2=1563894view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_private.h (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_private.h Mon Feb  3 13:50:14 2014
@@ -425,7 +425,7 @@ typedef struct {
  RENEG_INIT = 0, /* Before initial handshake */
  RENEG_REJECT, /* After initial handshake; any client-initiated
 * renegotiation should be rejected */
-RENEG_ALLOW, /* A server-initated renegotiation is taking
+RENEG_ALLOW, /* A server-initiated renegotiation is taking
* place (as dictated by configuration) */
  RENEG_ABORT /* Renegotiation initiated by client, abort the
   * connection */

Re: svn commit: r1563894 - in /httpd/httpd/trunk/modules/ssl: ssl_engine_kernel.c ssl_private.h

[Mike Rumph]

I  think the following change is also valid:

s/setup/set up/when used as a verb.

On 2/3/2014 7:55 AM, Mike Rumph wrote:

Hello Jeff,

s/limitiations/limitations/

Thanks,

Mike Rumph

On 2/3/2014 5:50 AM, traw...@apache.org wrote:

Author: trawick
Date: Mon Feb  3 13:50:14 2014
New Revision: 1563894

URL: http://svn.apache.org/r1563894
Log:
fix a few spelling errors

Modified:
 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_kernel.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1563894r1=1563893r2=1563894view=diff
== 


--- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Mon Feb  3 
13:50:14 2014

@@ -176,8 +176,8 @@ int ssl_hook_ReadReq(request_rec *r)
   * cause us to end up in a different virtual host as 
the one that
   * was used for the handshake causing different SSL 
parameters to
   * be applied as SSLProtocol, SSLCACertificateFile/Path 
and
- * SSLCADNRequestFile/Path cannot be renegotioated 
(SSLCA* due

- * to current limitiations in Openssl, see
+ * SSLCADNRequestFile/Path cannot be renegotiated 
(SSLCA* due

+ * to current limitiations in OpenSSL, see
   * 
http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3c48592955.2090...@velox.ch%3E

   * and
   * 
http://mail-archives.apache.org/mod_mbox/httpd-dev/201312.mbox/%3CCAKQ1sVNpOrdiBm-UPw1hEdSN7YQXRRjeaT-MCWbW_7mN%3DuFiOw%40mail.gmail.com%3E

@@ -207,7 +207,7 @@ int ssl_hook_ReadReq(request_rec *r)
  /*
   * We are using a name based configuration here, but no 
hostname was
   * provided via SNI. Don't allow that if are requested 
to do strict
- * checking. Check wether this strict checking was setup 
either in the
+ * checking. Check whether this strict checking was 
setup either in the
   * server config we used for handshaking or in our 
current server.

   * This should avoid insecure configuration by accident.
   */
@@ -1904,7 +1904,7 @@ void ssl_callback_Info(const SSL *ssl, i
  }
  }
  /* If the first handshake is complete, change state to reject any
- * subsequent client-initated renegotiation. */
+ * subsequent client-initiated renegotiation. */
  else if ((where  SSL_CB_HANDSHAKE_DONE)  scr-reneg_state == 
RENEG_INIT) {

  scr-reneg_state = RENEG_REJECT;
  }
@@ -2033,7 +2033,7 @@ static int ssl_find_vhost(void *serverna
   * vhost we have just switched to. Again, we have to make sure
   * that we're not overwriting a session id context which was
   * possibly set in ssl_hook_Access(), before triggering
- * a renegotation.
+ * a renegotiation.
   */
  if (SSL_num_renegotiations(ssl) == 0) {
  unsigned char *sid_ctx =

Modified: httpd/httpd/trunk/modules/ssl/ssl_private.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?rev=1563894r1=1563893r2=1563894view=diff
== 


--- httpd/httpd/trunk/modules/ssl/ssl_private.h (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_private.h Mon Feb  3 13:50:14 2014
@@ -425,7 +425,7 @@ typedef struct {
  RENEG_INIT = 0, /* Before initial handshake */
  RENEG_REJECT, /* After initial handshake; any client-initiated
 * renegotiation should be rejected */
-RENEG_ALLOW, /* A server-initated renegotiation is taking
+RENEG_ALLOW, /* A server-initiated renegotiation is taking
* place (as dictated by configuration) */
  RENEG_ABORT /* Renegotiation initiated by client, abort the
   * connection */

ApacheCon 2014 question

[Mike Rumph]

Hello all,

I am trying to plan a trip to the ApacheCon 2014, April 7-9.
And I was wondering if there are any plans for Apache httpd project 
specific events (such as hackathons or developer days) before or after 
these dates?


Thanks,

Mike Rumph

Re: Looking to TR 2.4.8 in Feb...

[Mike Rumph]

Hello Jim,

I would like to make a suggestion that is off topic from the last couple 
of replies but pertinent to a TR of 2.4.8.


If anyone is interested in having mod_remoteip work correctly in Apache 
httpd 2.4.8,

then the following bug reports and patches might be worth considering:

- https://issues.apache.org/bugzilla/show_bug.cgi?id=54651
- This is my reworking to an attachment of a patch that was first 
presented over a year ago.
- This is an essential patch for mod_remoteip to correctly process 
RemoteIPHeader headers that contain a list of IP addresses.


- https://issues.apache.org/bugzilla/show_bug.cgi?id=55972
- This is a fix to an obvious error that I recently discovered 
while studying mod_remoteip.c.


- https://issues.apache.org/bugzilla/show_bug.cgi?id=55962
- This is my implementation of an idea suggested by William A. Rowe Jr.
- This one could bring a slight improvement in behavior to some 
unlikely use cases.


- https://issues.apache.org/bugzilla/show_bug.cgi?id=55886
- This one is analysis on the question of what should appear in the 
client field on the server-status page after mod_remoteip works its magic.


I am available to help with any further work that might be needed here.

Thanks,

Mike Rumph



On 1/9/2014 5:33 AM, Jim Jagielski wrote:

defect?

We support UDS in ProxyPass. We don't in mod_rewrite.
Nor do we claim to. I don't think that's a defect.

If later on UDS support is *also* added to mod_rewrite,
then good. But not having it there isn't, IMO, any
reason to not include it where we say it is, and
where we see it works.

On Jan 9, 2014, at 1:29 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote:


On Mon, 6 Jan 2014 15:01:58 -0500
Jim Jagielski j...@jagunet.com wrote:


On Jan 6, 2014, at 2:40 PM, Blaise Tarr blaise.t...@gmail.com wrote:

So mod_rewrite is not recognizing the unix: prefix as being
valid. I temporarily commented out the call of fully_qualify_uri(r)
at mod_rewrite.c:4130, and now r-filename is set correctly:


Yes, right now the UDS support is only valid directly via mod_proxy,
and the required hooks in mod_rewrite need to be done and
currently isn't supported.

I don't see that as a big issue, currently. ;)

No, it's currently not an issue, we haven't introduced that defect into
a release branch.

Are you suggesting we hold off on the UDS support?  Or the 2.4.8 tag?
Or that new defects are interesting challenges for users?

Re: [PATCH] mod_remoteip

[Mike Rumph]

On 12/13/2013 5:03 PM, William A. Rowe Jr. wrote:
 There is nothing I see in the code that prevents a cycle with internal 
proxy from following a cycle with external proxy.


It's been several years so I was going from memory, but you are right...

 So if your explanation is the way the code is intended, there may 
exist some subtle  error cases.


Yes, the 'fail case' illustrated simply prevented the trusted proxy 
from presenting a private address.


I think this is an error, that it should have further prevented a a 
trusted proxy from returning to the

internal proxy list, and patches are welcome.

I attached a patch to implement this idea with the following interpretation:
Allow an internal proxy to present an external proxy, but do not allow 
an external proxy to present an internal proxy.

In this case the presented internal proxy will be considered external.
The patch also documents the case where no RemoteIPInternalProxy, 
RemoteIPInternalProxyList, RemoteIPTrustedProxy  or 
RemoteIPTrustedProxyList directives are configured at all.


So what do you think, Bill?

I also further endorse the patch in bug 54651 as essential.
- https://issues.apache.org/bugzilla/show_bug.cgi?id=54651
That patch should be committed to trunk and backported.
Without that patch, RemoteIPHeader headers containing a list of more 
than one IP address are not processed correctly.


There's one other enhancement I've wanted to make, to accept an trust 
as internal another
RemoteIPInternalHeader value from any routing appliances. 
 Said appliance would be responsible
for dropping any incoming value from the client, and replacing it with 
an absolute header or list
of headers.  Typical routing solutions use X-Remote-IP or similar 
headers to convey this info.

So are you suggesting RemoteIPInternalHeader as a new directive?
I have some time to look into this as well.


So the processing order would be the values in the 
RemoteIPInternalHeader list, followed by
the RemoteIPHeader values matching the RemoteIPInternalProxy 
http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteipinternalproxylist lists, 
and then restricted to
extranet addresses presented by the RemoteIPTrustedProxy 
http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteipinternalproxylist list. 



But in enforcing this change, some configurations are likely to be 
broken where users have an
assorted collection of Internal and Trusted Proxy members which don't 
actually follow this

design, so we might be a bit late in changing this before 2.6.



Index: modules/metadata/mod_remoteip.c
===
--- modules/metadata/mod_remoteip.c (revision 1552356)
+++ modules/metadata/mod_remoteip.c (working copy)
@@ -230,12 +230,25 @@
 char *parse_remote;
 char *eos;
 unsigned char *addrbyte;
+
+   /* If no RemoteIPInternalProxy, RemoteIPInternalProxyList, 
RemoteIPTrustedProxy 
+   or RemoteIPTrustedProxyList directive is configured,
+  all proxies will be considered as external trusted proxies.
+ */
 void *internal = NULL;
 
 if (!config-header_name) {
 return DECLINED;
 }
 
+if (config-proxymatch_ip) {
+   /* This indicates that a RemoteIPInternalProxy, 
RemoteIPInternalProxyList, RemoteIPTrustedProxy 
+   or RemoteIPTrustedProxyList directive is configured.
+   In this case, default to internal proxy.
+ */
+internal = (void *) 1;
+}
+
 remote = (char *) apr_table_get(r-headers_in, config-header_name);
 if (!remote) {
 return OK;
@@ -254,7 +267,13 @@
 match = (remoteip_proxymatch_t *)config-proxymatch_ip-elts;
 for (i = 0; i  config-proxymatch_ip-nelts; ++i) {
 if (apr_ipsubnet_test(match[i].ip, c-client_addr)) {
-internal = match[i].internal;
+if (internal) {
+   /* Allow an internal proxy to 
present an external proxy,
+   but do not allow an external proxy to present an 
internal proxy.
+   In this case the presented internal proxy will be 
considered external.
+ */
+internal = match[i].internal;
+}
 break;
 }
 }

Re: [PATCH] mod_remoteip

[Mike Rumph]

Viewing the patch as sent to the mailing list, points out unwanted tab 
characters.

So I reattached a patch with these characters removed.

Thanks,

Mike Rumph
On 12/19/2013 10:46 AM, Mike Rumph wrote:


On 12/13/2013 5:03 PM, William A. Rowe Jr. wrote:
 There is nothing I see in the code that prevents a cycle with 
internal proxy from following a cycle with external proxy.


It's been several years so I was going from memory, but you are right...

 So if your explanation is the way the code is intended, there may 
exist some subtle  error cases.


Yes, the 'fail case' illustrated simply prevented the trusted proxy 
from presenting a private address.


I think this is an error, that it should have further prevented a a 
trusted proxy from returning to the

internal proxy list, and patches are welcome.
I attached a patch to implement this idea with the following 
interpretation:
Allow an internal proxy to present an external proxy, but do not allow 
an external proxy to present an internal proxy.

In this case the presented internal proxy will be considered external.
The patch also documents the case where no RemoteIPInternalProxy, 
RemoteIPInternalProxyList, RemoteIPTrustedProxy  or 
RemoteIPTrustedProxyList directives are configured at all.


So what do you think, Bill?

I also further endorse the patch in bug 54651 as essential.
- https://issues.apache.org/bugzilla/show_bug.cgi?id=54651
That patch should be committed to trunk and backported.
Without that patch, RemoteIPHeader headers containing a list of more 
than one IP address are not processed correctly.


There's one other enhancement I've wanted to make, to accept an trust 
as internal another
RemoteIPInternalHeader value from any routing appliances. 
 Said appliance would be responsible
for dropping any incoming value from the client, and replacing it 
with an absolute header or list
of headers.  Typical routing solutions use X-Remote-IP or similar 
headers to convey this info.

So are you suggesting RemoteIPInternalHeader as a new directive?
I have some time to look into this as well.


So the processing order would be the values in the 
RemoteIPInternalHeader list, followed by
the RemoteIPHeader values matching the RemoteIPInternalProxy 
http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteipinternalproxylist lists, 
and then restricted to
extranet addresses presented by the RemoteIPTrustedProxy 
http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteipinternalproxylist list. 



But in enforcing this change, some configurations are likely to be 
broken where users have an
assorted collection of Internal and Trusted Proxy members which don't 
actually follow this

design, so we might be a bit late in changing this before 2.6.





Index: modules/metadata/mod_remoteip.c
===
--- modules/metadata/mod_remoteip.c (revision 1552356)
+++ modules/metadata/mod_remoteip.c (working copy)
@@ -230,12 +230,25 @@
 char *parse_remote;
 char *eos;
 unsigned char *addrbyte;
+
+/* If no RemoteIPInternalProxy, RemoteIPInternalProxyList, 
RemoteIPTrustedProxy 
+   or RemoteIPTrustedProxyList directive is configured,
+   all proxies will be considered as external trusted proxies.
+ */
 void *internal = NULL;
 
 if (!config-header_name) {
 return DECLINED;
 }
 
+if (config-proxymatch_ip) {
+/* This indicates that a RemoteIPInternalProxy, 
RemoteIPInternalProxyList, RemoteIPTrustedProxy 
+   or RemoteIPTrustedProxyList directive is configured.
+   In this case, default to internal proxy.
+ */
+internal = (void *) 1;
+}
+
 remote = (char *) apr_table_get(r-headers_in, config-header_name);
 if (!remote) {
 return OK;
@@ -254,7 +267,13 @@
 match = (remoteip_proxymatch_t *)config-proxymatch_ip-elts;
 for (i = 0; i  config-proxymatch_ip-nelts; ++i) {
 if (apr_ipsubnet_test(match[i].ip, c-client_addr)) {
-internal = match[i].internal;
+if (internal) {
+/* Allow an internal proxy to present an external 
proxy,
+   but do not allow an external proxy to present an 
internal proxy.
+   In this case, the presented internal proxy will be 
considered external.
+ */
+internal = match[i].internal;
+}
 break;
 }
 }

Re: mod_remoteip

[Mike Rumph]

Hello Eugene,

Thanks for pointing out your bug report 54651.
It answers a mystery I had with regard to bug report 55635.
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55635
As you can see in comment 1, I submitted results that were somewhat 
different from those of the bug reporter.

In comment 3, I gave an explanation of the bug reporter's results.
But that did not explain my own results.

Once I applied your patch from bug 54651, my results matched those of 
the bug reporter in 55635.

It appears that the bug reporter in 55635 had the patch for 54651 applied.
So I confirm that your patch is indeed valid and useful.

Since I am a relatively new developer (1 year) for the Apache httpd 
project, I do not have committer access.
Perhaps there is a committer who is interested in mod_remoteip that will 
consider committing the 54651 patch to trunk.

I will update bug 54651 to help bring it some attention.

Thanks again,

Mike Rumph

On 12/15/2013 1:00 AM, Lam, Eugene wrote:

Secondly, with each cycle of the while loop the apparent client IP is

compared against the proxymatch_ip list.

Are you referring to the while loop here:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/metadata/mod_remotei
p.c?view=markuppathrev=1550828#l247

Not to detract from the original topic, but while we're here, an equally
serious bug does exists on line 256 ... with a simple fix.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54651

If anyone would kindly verify and integrate the provided patch, this 1
year old bug can be put to bed.

EugeneL

On 12/13/13 4:26 PM, Mike Rumph mike.ru...@oracle.com wrote:


On 12/11/2013 2:18 PM, William A. Rowe Jr. wrote:

On Mon, 09 Dec 2013 11:10:46 -0800
Mike Rumph mike.ru...@oracle.com wrote:


As you can see from the bug report, I have been looking into this.
It might also be important to  consider the related bug 55637:
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55637

Closed invalid.  The incorrect assumptions are very similar to but
distinct from the 55635 case.

In this case, let's use a car's title as it's internal proxy document
and the car's ignition keys as the trusted proxy document.  Although
you might trust one with your car keys, they can go ahead and share
those keys with yet another party.  We would not want to design the
remoteip logic to then let that individual hand another party the title
to the vehicle :)  Once the InternalProxy list is exhausted and we have
begun processing the TrustedProxy list, we can never again assign the
next apparent proxy to be an InternalProxy.  That would be a claim by
an external party whom we can't assign that much trust to.

So I think you are referring to the difference between
RemoteIPInternalProxy and RemoteIPTrustedProxy, correct?
Your explanation sounds reasonable, but to me it doesn't appear to
exactly match the actual implementation in mod_remoteip.c.

First of all, both directives are combined into one single list (not two).
In remoteip_modify_request() this is referred to as config-proxymatch_ip.
The elements within this list are distinguished by the internal field.
RemoteIPInternalProxy elements are marked as internal, while
RemoteIPTrustedProxy elements are not.
The only difference in processing of the internal field is in the
handling of local/private subnets.
So as I read the code, it is not a difference in level of trust, but
rather a matter of name space.
This makes sense to me.
For example, IP address 10.1.2.3 only has meaning within a specific
local network.
So if an external proxy is referring to 10.1.2.3, it would probably not
be intending a server in the local network that just happens to have
10.1.2.3 has its IP address.

Secondly, with each cycle of the while loop the apparent client IP is
compared against the proxymatch_ip list.
It may be internal or not.
There is nothing I see in the code that prevents a cycle with internal
proxy from following a cycle with external proxy.

So if your explanation is the way the code is intended, there may exist
some subtle  error cases.
Experiments to investigate this could take us outside the scope of the
original bug reports, so I decided to discuss it here instead.


The setups so far have not included a RemoteIPProxiesHeader.
But if it is included, the mod_remote documentation seems to indicate
that the value should be different from the RemoteIPHeader.
-

http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipproxies
header

RemoteIPHeader  X-Forwarded-For
RemoteIPProxiesHeader  X-Forwarded-By

You are correct.


  From my analysis so far it appears that mod_remoteip is behaving as
documented. But the documentation is a little difficult to understand.

Correct, and I'm not sure how it can be improved.  Feel free to quote,
rephrase or build upon my responses to the bug tickets.

Re: Some redundant code and comment typos in mod_remoteip

[Mike Rumph]

equivalant versus equivalent
Perhaps this is a difference in British versus American spelling, correct?

Anyway, thanks for the commits.

Mike Rumph

On 12/12/2013 10:12 PM, Christophe JAILLET wrote:

Trunk
=
r1550650 for comments upodate
r1550651 for redundant check


2.4.x
=
r1550652 for comments upodate
The other one will be proposed for backport with other easy patches to 
synch 2.4 and trunk in the coming days.



BTW, for someone who has write access to APR tree, 
s/equivilant/equivalant/ in incluce/arch/netware/apr_private.h


Thx,
CJ

Re: mod_remoteip

[Mike Rumph]

On 12/11/2013 2:18 PM, William A. Rowe Jr. wrote:

On Mon, 09 Dec 2013 11:10:46 -0800
Mike Rumph mike.ru...@oracle.com wrote:


As you can see from the bug report, I have been looking into this.
It might also be important to  consider the related bug 55637:
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55637

Closed invalid.  The incorrect assumptions are very similar to but
distinct from the 55635 case.

In this case, let's use a car's title as it's internal proxy document
and the car's ignition keys as the trusted proxy document.  Although
you might trust one with your car keys, they can go ahead and share
those keys with yet another party.  We would not want to design the
remoteip logic to then let that individual hand another party the title
to the vehicle :)  Once the InternalProxy list is exhausted and we have
begun processing the TrustedProxy list, we can never again assign the
next apparent proxy to be an InternalProxy.  That would be a claim by
an external party whom we can't assign that much trust to.
So I think you are referring to the difference between 
RemoteIPInternalProxy and RemoteIPTrustedProxy, correct?
Your explanation sounds reasonable, but to me it doesn't appear to 
exactly match the actual implementation in mod_remoteip.c.


First of all, both directives are combined into one single list (not two).
In remoteip_modify_request() this is referred to as config-proxymatch_ip.
The elements within this list are distinguished by the internal field.
RemoteIPInternalProxy elements are marked as internal, while 
RemoteIPTrustedProxy elements are not.
The only difference in processing of the internal field is in the 
handling of local/private subnets.
So as I read the code, it is not a difference in level of trust, but 
rather a matter of name space.

This makes sense to me.
For example, IP address 10.1.2.3 only has meaning within a specific 
local network.
So if an external proxy is referring to 10.1.2.3, it would probably not 
be intending a server in the local network that just happens to have 
10.1.2.3 has its IP address.


Secondly, with each cycle of the while loop the apparent client IP is 
compared against the proxymatch_ip list.

It may be internal or not.
There is nothing I see in the code that prevents a cycle with internal 
proxy from following a cycle with external proxy.


So if your explanation is the way the code is intended, there may exist 
some subtle  error cases.
Experiments to investigate this could take us outside the scope of the 
original bug reports, so I decided to discuss it here instead.





The setups so far have not included a RemoteIPProxiesHeader.
But if it is included, the mod_remote documentation seems to indicate
that the value should be different from the RemoteIPHeader.
-
http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipproxiesheader

RemoteIPHeader  X-Forwarded-For
RemoteIPProxiesHeader  X-Forwarded-By

You are correct.


 From my analysis so far it appears that mod_remoteip is behaving as
documented. But the documentation is a little difficult to understand.

Correct, and I'm not sure how it can be improved.  Feel free to quote,
rephrase or build upon my responses to the bug tickets.

Re: Some redundant code and comment typos in mod_remoteip

[Mike Rumph]

Hello Bill,

Thanks for the advice.

Leaving filename as is is okay for me, I just thought I saw it split at 
other places in the code comments.
So should I resubmit the patch or is one of the  committers okay with 
picking and choosing?
The patch overall was just some small things that I noticed and thought 
were worth mentioning.


Mike Rumph



On 12/12/2013 9:34 AM, William A. Rowe Jr. wrote:

On Wed, 04 Dec 2013 11:25:32 -0800
Mike Rumph mike.ru...@oracle.com wrote:


While researching mod_remoteip to work on httpd bugs 55635 and 55637,
I noticed a few unrelated blemishes in mod_remoteip.c.
These include some redundant code and comment typos.

The attached patch against httpd trunk should address these.

Some comments below, but most importantly, you might offer patches with
non-code, documentation fixes separately from actual code changes, for
the most efficient processing.  Almost any committer here feels very
comfortable reviewing typo-correction patches, but you'll be waiting on
someone who feels comfortable with the specific code before your code
changes could be applied.

Reordered, with feedback to specific items;


Index: modules/metadata/mod_remoteip.c
===
--- modules/metadata/mod_remoteip.c (revision 1547874)
+++ modules/metadata/mod_remoteip.c (working copy)
@@ -37,11 +37,11 @@
  } remoteip_proxymatch_t;
  
  typedef struct {

-/** The header to retrieve a proxy-via ip list */
+/** The header to retrieve a proxy-via IP list */
  const char *header_name;
  /** A header to record the proxied IP's
   * (removed as the physical connection and
- * from the proxy-via ip header value list)
+ * from the proxy-via IP header value list)
   */
  const char *proxies_header_name;
  /** A list of trusted proxies, ideally configured
@@ -53,9 +53,9 @@
  typedef struct {
  apr_sockaddr_t *useragent_addr;
  char *useragent_ip;
-/** The list of proxy ip's ignored as remote ip's */
+/** The list of proxy IP's ignored as remote IP's */
  const char *proxy_ips;
-/** The remaining list of untrusted proxied remote ip's */
+/** The remaining list of untrusted proxied remote IP's */
  const char *proxied_remote;
  } remoteip_req_t;
@@ -290,7 +290,7 @@
  break;
  }
  
-/* We map as IPv4 rather than IPv6 for equivilant host names

+/* We map as IPv4 rather than IPv6 for equivalent host names
   * or IPV4OVERIPV6
   */
  rv = apr_sockaddr_info_get(temp_sa,  parse_remote,
@@ -309,7 +309,6 @@
  remote = parse_remote;
  }
  break;
-
  }
  
  addrbyte = (unsigned char *) temp_sa-sa.sin.sin_addr;
  


Good changes above.



@@ -198,7 +198,7 @@
  while (!(ap_cfg_getline(lbuf, MAX_STRING_LEN, cfp))) {
  args = lbuf;
  while (*(arg = ap_getword_conf(cmd-temp_pool, args)) !=
'\0') {
-if (*arg == '#' || *arg == '\0') {
+if (*arg == '#') {
  break;
  }
  errmsg = proxies_set(cmd, cfg, arg);

Why are you eliminating a one byte-test bypass of empty lines?


@@ -111,7 +111,7 @@
  static int looks_like_ip(const char *ipstr)
  {
  if (ap_strchr_c(ipstr, ':')) {
-/* definitely not a hostname; assume it is intended to be an
IPv6 address */
+/* definitely not a host name; assume it is intended to be an
IPv6 address */ return 1;
  }
  
Unnecessary and inaccurate doc change that most any internet project

would reject.  hostname has a specific compsci definition.  You might
want to add it to your conventional dictionary.


@@ -422,11 +422,11 @@
  which are trusted to present IP headers),
  AP_INIT_TAKE1(RemoteIPTrustedProxyList, proxylist_read, 0,
RSRC_CONF | EXEC_ON_READ,
-  The filename to read the list of trusted proxies, 
+  The file name to read the list of trusted proxies, 
see the RemoteIPTrustedProxy directive),
  AP_INIT_TAKE1(RemoteIPInternalProxyList, proxylist_read,
(void*)1, RSRC_CONF | EXEC_ON_READ,
-  The filename to read the list of internal proxies, 
+  The file name to read the list of internal proxies,
see the RemoteIPTrustedProxy directive),
  { NULL }
  };

Again, a common compsci term with a well understood meaning.
You will find such phrases throughout the project... so your patch
request is essentially a request for a style change.  I'm -1 on that
particular one.

Re: Some redundant code and comment typos in mod_remoteip

[Mike Rumph]

Just to make things easier here are the separate patches with your ideas 
included.


Thanks,

Mike Rumph

On 12/12/2013 1:37 PM, Mike Rumph wrote:

Hello Bill,

Thanks for the advice.

Leaving filename as is is okay for me, I just thought I saw it split 
at other places in the code comments.
So should I resubmit the patch or is one of the  committers okay with 
picking and choosing?
The patch overall was just some small things that I noticed and 
thought were worth mentioning.


Mike Rumph



On 12/12/2013 9:34 AM, William A. Rowe Jr. wrote:

On Wed, 04 Dec 2013 11:25:32 -0800
Mike Rumph mike.ru...@oracle.com wrote:


While researching mod_remoteip to work on httpd bugs 55635 and 55637,
I noticed a few unrelated blemishes in mod_remoteip.c.
These include some redundant code and comment typos.

The attached patch against httpd trunk should address these.

Some comments below, but most importantly, you might offer patches with
non-code, documentation fixes separately from actual code changes, for
the most efficient processing.  Almost any committer here feels very
comfortable reviewing typo-correction patches, but you'll be waiting on
someone who feels comfortable with the specific code before your code
changes could be applied.

Reordered, with feedback to specific items;


Index: modules/metadata/mod_remoteip.c
===
--- modules/metadata/mod_remoteip.c(revision 1547874)
+++ modules/metadata/mod_remoteip.c(working copy)
@@ -37,11 +37,11 @@
  } remoteip_proxymatch_t;
typedef struct {
-/** The header to retrieve a proxy-via ip list */
+/** The header to retrieve a proxy-via IP list */
  const char *header_name;
  /** A header to record the proxied IP's
   * (removed as the physical connection and
- * from the proxy-via ip header value list)
+ * from the proxy-via IP header value list)
   */
  const char *proxies_header_name;
  /** A list of trusted proxies, ideally configured
@@ -53,9 +53,9 @@
  typedef struct {
  apr_sockaddr_t *useragent_addr;
  char *useragent_ip;
-/** The list of proxy ip's ignored as remote ip's */
+/** The list of proxy IP's ignored as remote IP's */
  const char *proxy_ips;
-/** The remaining list of untrusted proxied remote ip's */
+/** The remaining list of untrusted proxied remote IP's */
  const char *proxied_remote;
  } remoteip_req_t;
@@ -290,7 +290,7 @@
  break;
  }
  -/* We map as IPv4 rather than IPv6 for equivilant host names
+/* We map as IPv4 rather than IPv6 for equivalent host names
   * or IPV4OVERIPV6
   */
  rv = apr_sockaddr_info_get(temp_sa, parse_remote,
@@ -309,7 +309,6 @@
  remote = parse_remote;
  }
  break;
-
  }
addrbyte = (unsigned char *) temp_sa-sa.sin.sin_addr;

Good changes above.



@@ -198,7 +198,7 @@
  while (!(ap_cfg_getline(lbuf, MAX_STRING_LEN, cfp))) {
  args = lbuf;
  while (*(arg = ap_getword_conf(cmd-temp_pool, args)) !=
'\0') {
-if (*arg == '#' || *arg == '\0') {
+if (*arg == '#') {
  break;
  }
  errmsg = proxies_set(cmd, cfg, arg);

Why are you eliminating a one byte-test bypass of empty lines?


@@ -111,7 +111,7 @@
  static int looks_like_ip(const char *ipstr)
  {
  if (ap_strchr_c(ipstr, ':')) {
-/* definitely not a hostname; assume it is intended to be an
IPv6 address */
+/* definitely not a host name; assume it is intended to be an
IPv6 address */ return 1;
  }
  Unnecessary and inaccurate doc change that most any internet project
would reject.  hostname has a specific compsci definition.  You might
want to add it to your conventional dictionary.


@@ -422,11 +422,11 @@
  which are trusted to present IP headers),
  AP_INIT_TAKE1(RemoteIPTrustedProxyList, proxylist_read, 0,
RSRC_CONF | EXEC_ON_READ,
-  The filename to read the list of trusted proxies, 
+  The file name to read the list of trusted proxies, 
see the RemoteIPTrustedProxy directive),
  AP_INIT_TAKE1(RemoteIPInternalProxyList, proxylist_read,
(void*)1, RSRC_CONF | EXEC_ON_READ,
-  The filename to read the list of internal proxies, 
+  The file name to read the list of internal proxies,
see the RemoteIPTrustedProxy directive),
  { NULL }
  };

Again, a common compsci term with a well understood meaning.
You will find such phrases throughout the project... so your patch
request is essentially a request for a style change.  I'm -1 on that
particular one.








Index: modules/metadata/mod_remoteip.c
===
--- modules/metadata/mod_remoteip.c (revision 1550549)
+++ modules/metadata/mod_remoteip.c

Re: [PATCH]Some redundant code and comment typos in mod_remoteip

[Mike Rumph]

I forgot to add a [PATCH] tag on the front of the subject.

The changes here are minor, but they do make the code a little cleaner.

On 12/4/2013 11:25 AM, Mike Rumph wrote:

While researching mod_remoteip to work on httpd bugs 55635 and 55637,
I noticed a few unrelated blemishes in mod_remoteip.c.
These include some redundant code and comment typos.

The attached patch against httpd trunk should address these.

Thanks,

Mike Rumph

Re: mod_remoteip

[Mike Rumph]

As you can see from the bug report, I have been looking into this.
It might also be important to  consider the related bug 55637:
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55637

The setups so far have not included a RemoteIPProxiesHeader.
But if it is included, the mod_remote documentation seems to indicate 
that the value should be different from the RemoteIPHeader.
- 
http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipproxiesheader 



RemoteIPHeader  X-Forwarded-For
RemoteIPProxiesHeader  X-Forwarded-By

From my analysis so far it appears that mod_remoteip is behaving as documented.
But the documentation is a little difficult to understand.

Thanks,

Mike Rumph


On 12/9/2013 10:52 AM, Reindl Harald wrote:

Am 09.12.2013 19:28, schrieb Jim Jagielski:

This seems kinda serious

https://issues.apache.org/bugzilla/show_bug.cgi?id=55635

any remoteip people able to look into this?

i am willing to debug but i need a simplified
step-to-step what to look for and how to
reproduce if possible at all

the mod_remoteip config looks like below

RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy  LAN-IP of own http://trafficserver.apache.org/
RemoteIPProxiesHeader  X-Forwarded-For

Some redundant code and comment typos in mod_remoteip

[Mike Rumph]

While researching mod_remoteip to work on httpd bugs 55635 and 55637,
I noticed a few unrelated blemishes in mod_remoteip.c.
These include some redundant code and comment typos.

The attached patch against httpd trunk should address these.

Thanks,

Mike Rumph
Index: modules/metadata/mod_remoteip.c
===
--- modules/metadata/mod_remoteip.c (revision 1547874)
+++ modules/metadata/mod_remoteip.c (working copy)
@@ -37,11 +37,11 @@
 } remoteip_proxymatch_t;
 
 typedef struct {
-/** The header to retrieve a proxy-via ip list */
+/** The header to retrieve a proxy-via IP list */
 const char *header_name;
 /** A header to record the proxied IP's
  * (removed as the physical connection and
- * from the proxy-via ip header value list)
+ * from the proxy-via IP header value list)
  */
 const char *proxies_header_name;
 /** A list of trusted proxies, ideally configured
@@ -53,9 +53,9 @@
 typedef struct {
 apr_sockaddr_t *useragent_addr;
 char *useragent_ip;
-/** The list of proxy ip's ignored as remote ip's */
+/** The list of proxy IP's ignored as remote IP's */
 const char *proxy_ips;
-/** The remaining list of untrusted proxied remote ip's */
+/** The remaining list of untrusted proxied remote IP's */
 const char *proxied_remote;
 } remoteip_req_t;
 
@@ -111,7 +111,7 @@
 static int looks_like_ip(const char *ipstr)
 {
 if (ap_strchr_c(ipstr, ':')) {
-/* definitely not a hostname; assume it is intended to be an IPv6 
address */
+/* definitely not a host name; assume it is intended to be an IPv6 
address */
 return 1;
 }
 
@@ -198,7 +198,7 @@
 while (!(ap_cfg_getline(lbuf, MAX_STRING_LEN, cfp))) {
 args = lbuf;
 while (*(arg = ap_getword_conf(cmd-temp_pool, args)) != '\0') {
-if (*arg == '#' || *arg == '\0') {
+if (*arg == '#') {
 break;
 }
 errmsg = proxies_set(cmd, cfg, arg);
@@ -290,7 +290,7 @@
 break;
 }
 
-/* We map as IPv4 rather than IPv6 for equivilant host names
+/* We map as IPv4 rather than IPv6 for equivalent host names
  * or IPV4OVERIPV6
  */
 rv = apr_sockaddr_info_get(temp_sa,  parse_remote,
@@ -309,7 +309,6 @@
 remote = parse_remote;
 }
 break;
-
 }
 
 addrbyte = (unsigned char *) temp_sa-sa.sin.sin_addr;
@@ -422,11 +421,11 @@
 which are trusted to present IP headers),
 AP_INIT_TAKE1(RemoteIPTrustedProxyList, proxylist_read, 0,
   RSRC_CONF | EXEC_ON_READ,
-  The filename to read the list of trusted proxies, 
+  The file name to read the list of trusted proxies, 
   see the RemoteIPTrustedProxy directive),
 AP_INIT_TAKE1(RemoteIPInternalProxyList, proxylist_read, (void*)1,
   RSRC_CONF | EXEC_ON_READ,
-  The filename to read the list of internal proxies, 
+  The file name to read the list of internal proxies, 
   see the RemoteIPInternalProxy directive),
 { NULL }
 };

Re: False positive errno test after call to strtol()

[Mike Rumph]

Thanks Jeff,

Here is an example with no validation:
modules/aaa/mod_auth_digest.c (lines 980 - 982):

if (resp-opaque) {
resp-opaque_num = (unsigned long) strtol(resp-opaque, NULL, 16);
}

Here is an example with limited validation:
server/log.c (lines 1590 - 1600):
===
/* If we fill the buffer, we're probably reading a corrupt pid file.
 * To be nice, let's also ensure the first char is a digit. */
if (bytes_read == 0 || bytes_read == BUFFER_SIZE - 1 || 
!apr_isdigit(*buf)) {

return APR_EGENERAL;
}

buf[bytes_read] = '\0';
*mypid = strtol(buf, endptr, 10);


Here is a typical example of endptr validation:
modules/proxy/mod_proxy_connect.c (lines 91 - 108):
===
const char *p = arg;

if (!apr_isdigit(arg[0]))
return AllowCONNECT: port numbers must be numeric;

first = strtol(p, endptr, 10);
if (*endptr == '-') {
p = endptr + 1;
last = strtol(p, endptr, 10);
}
else {
last = first;
}

if (endptr == p || *endptr != '\0')  {
return apr_psprintf(parms-temp_pool,
Cannot parse '%s' as port number, p);
}

(There is no ERANGE checking for numeric overflow.)
(Also none of the calls to strtol() in Apache httpd and APR check for 
EINVAL.)


If I were to work on a more extensive patch, I would consider each case 
to see if further validation would be warranted.


Take care,

Mike


On 11/15/2013 9:38 AM, Jeff Trawick wrote:
On Thu, Nov 14, 2013 at 4:11 PM, Mike Rumph mike.ru...@oracle.com 
mailto:mike.ru...@oracle.com wrote:


The man page for strtol() indicate that the function can set errno
to ERANGE (EINVAL is also possible for some environments).
But for the errno check to be valid errno should be set to 0
before the function call.
- http://linux.die.net/man/3/strtol

I've reviewed all cases of calls to strtol() in httpd and APR code.
In some cases no validation is performed after the call.
In most cases endptr (the second parameter) is checked against the
beginning and/or ending of the string which does not guarantee
against numeric overflow.
In some cases errno is checked for ERANGE.

I've attached a patch for the simplest case, where errno is
checked but was not set to 0 before the call.


committed to trunk as r1542338; I'll propose for backport to the 2.4.x 
branch



I will consider working up a more extensive patch, if it is desired.


I suggest posting a couple of examples of what you found first.


BTW, this discussion is not purely theoretical.
Erroneous Invalid ThreadStackSize value:  messages have been
witnessed in HP-UX environments.

Thanks,

Mike Rumph




--
Born in Roswell... married an alien...
http://emptyhammock.com/

False positive errno test after call to strtol()

[Mike Rumph]

The man page for strtol() indicate that the function can set errno to 
ERANGE (EINVAL is also possible for some environments).
But for the errno check to be valid errno should be set to 0 before the 
function call.

- http://linux.die.net/man/3/strtol

I've reviewed all cases of calls to strtol() in httpd and APR code.
In some cases no validation is performed after the call.
In most cases endptr (the second parameter) is checked against the 
beginning and/or ending of the string which does not guarantee against 
numeric overflow.

In some cases errno is checked for ERANGE.

I've attached a patch for the simplest case, where errno is checked but 
was not set to 0 before the call.


I will consider working up a more extensive patch, if it is desired.

BTW, this discussion is not purely theoretical.
Erroneous Invalid ThreadStackSize value:  messages have been witnessed 
in HP-UX environments.


Thanks,

Mike Rumph
Index: server/mpm_common.c
===
--- server/mpm_common.c (revision 1542069)
+++ server/mpm_common.c (working copy)
@@ -389,6 +389,7 @@
 return err;
 }
 
+errno = 0;
 value = strtol(arg, NULL, 10);
 if (value  0 || errno == ERANGE)
 return apr_pstrcat(cmd-pool, Invalid MaxMemFree value: ,
@@ -408,6 +409,7 @@
 return err;
 }
 
+errno = 0;
 value = strtol(arg, NULL, 10);
 if (value  0 || errno == ERANGE)
 return apr_pstrcat(cmd-pool, Invalid ThreadStackSize value: ,

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Mike Rumph]

I tried the configuration below with httpd trunk:

 RewriteEngine On

 RewriteCond %{HTTPS} =off
 RewriteRule . - [E=protocol:http]
 RewriteCond %{HTTPS} =on
 RewriteRule . - [E=protocol:https]

 RewriteRule ^/my_app/(.*) %{protocol}://1.2.3.4/my_app/$1 [P]
 ProxyPassReverse /my_app/ http://1.2.3.4/my_app/
 ProxyPassReverse /my_app/ https://1.2.3.4/my_app/

Then browsing to http://1.2.3.4/my_app/ gives me the following result:

*Not Found*

The requested URL /://1.2.3.4/my_app/ was not found on this server.

Any other suggestions?

Thanks,

Mike

On 9/17/2013 9:32 AM, Jim Jagielski wrote:

+1

On Sep 17, 2013, at 11:32 AM, Jeff Trawick traw...@gmail.com wrote:


On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group 
ruediger.pl...@vodafone.com wrote:
IMHO yes. But I am a mod_rewrite fan anyway :-).

not really a rewrite fan, but I think that's better than code

so IMO we should doc that interpolation isn't supported in the scheme, and 
instead a solution like that should be used

  


Regards

Rüdiger


-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Dienstag, 17. September 2013 17:26
To: dev@httpd.apache.org
Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by
regression to APR-util 1.5.2

Doesn't that completely avoid/ignore the issue in the 1st place?

On Sep 17, 2013, at 11:08 AM, Plüm, Rüdiger, Vodafone Group
ruediger.pl...@vodafone.com wrote:


How about

  RewriteEngine On

  RewriteCond %{HTTPS} =off
  RewriteRule . - [E=protocol:http]
  RewriteCond %{HTTPS} =on
  RewriteRule . - [E=protocol:https]

  RewriteRule ^/my_app/(.*) %{protocol}://1.2.3.4/my_app/$1 [P]
  ProxyPassReverse /my_app/ http://1.2.3.4/my_app/
  ProxyPassReverse /my_app/ https://1.2.3.4/my_app/

?

Regards

Rüdiger

From: Jeff Trawick [mailto:traw...@gmail.com]
Sent: Dienstag, 17. September 2013 15:24
To: Apache HTTP Server Development List
Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by

regression to APR-util 1.5.2

On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph mike.ru...@oracle.com

wrote:

Hello Jeff,

Thanks for your reply.


On 9/3/2013 6:58 AM, Jeff Trawick wrote:

Since the URL validation in apr_uri_parse() has been tightened in the

handling of the scheme portion of a URL,

I submitted a patch to httpd bug 55315 against the mod_proxy code in

httpd trunk to handle the special case

of interpolating a variable in the scheme portion of a URL.

- https://issues.apache.org/bugzilla/show_bug.cgi?id=55315


Do you know if it is practical to have the one magic path down to

ap_proxy_define_worker() munge the URI?  I guess the problem is that
ap_proxy_define_worker() saves the parsed uri, and the caller (add_pass
or whatever it is) doesn't have access to that?

I take your point to be that the mod_proxy patch I submitted cannot be

applied to the branches, since it changes the API.

So I've submitted a new patch that is applied further up the stack in

add_pass() in mod_proxy.c.

That patch

(https://issues.apache.org/bugzilla/attachment.cgi?id=30799) is the one
I'm considering, as it is the one that could solve the issue for 2.2.x
(with a minor tweak) and 2.4.x (as-is), and I don't think the function
API issue is the major concern.  Instead, carrying the interpolation
expression around in the worker scheme field separate from an
interpolation flag seems to be the overriding issue.

Dynamic determination of the scheme seems very useful and I don't know

of another way to implement the same requirement, which is well
illustrated by the now-broken config in the bug:

  ProxyPassInterpolateEnv On
  RewriteEngine On

  RewriteCond %{HTTPS} =off
  RewriteRule . - [E=protocol:http]
  RewriteCond %{HTTPS} =on
  RewriteRule . - [E=protocol:https]

  ProxyPass /my_app/ ${protocol}://1.2.3.4/my_app/ interpolate
  ProxyPassReverse /my_app/ ${protocol}://1.2.3.4/my_app/

interpolate

Any alternate ideas for configuring something like that?

Otherwise, any objections to patch 30799 (URL above)?




It is interesting that my research seems to indicate that mod_proxy

interpolation was actually the first to be introduced into the code.

I guess the order is this:

1. support for environment variables in the config
2. mod_proxy interpolation
3. core server starts complaining if you have something that looks

like an envvar reference that isn't resolved

Is that what you mean?

The double use of ${} is nasty.  In the fullness of time, I think that

mod_proxy interpolation should support an additional syntax that doesn't
collide with the config-time processing.

Yes, that is the point that I was trying to make.

Thanks,

Mike Rumph



--
Born in Roswell... married an alien...
http://emptyhammock.com/




--
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [PATCH 55315] mod_proxy interpolation code broken by regression to APR-util 1.5.2

[Mike Rumph]

Sorry.

I got carried away with the generic translation.

I was instead browsing to http://localhost:8080/my_app/

With the results indicated below.

Thanks,

Mike Rumph


On 10/8/2013 1:09 PM, Mike Rumph wrote:

I tried the configuration below with httpd trunk:

  RewriteEngine On

  RewriteCond %{HTTPS} =off
  RewriteRule . - [E=protocol:http]
  RewriteCond %{HTTPS} =on
  RewriteRule . - [E=protocol:https]

  RewriteRule ^/my_app/(.*) %{protocol}://1.2.3.4/my_app/$1 [P]
  ProxyPassReverse /my_app/http://1.2.3.4/my_app/
  ProxyPassReverse /my_app/https://1.2.3.4/my_app/
Then browsing to http://1.2.3.4/my_app/ gives me the following result:

*Not Found*

The requested URL /://1.2.3.4/my_app/ was not found on this server.

Any other suggestions?

Thanks,

Mike

On 9/17/2013 9:32 AM, Jim Jagielski wrote:

+1

On Sep 17, 2013, at 11:32 AM, Jeff Trawicktraw...@gmail.com  wrote:


On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone 
Groupruediger.pl...@vodafone.com  wrote:
IMHO yes. But I am a mod_rewrite fan anyway :-).

not really a rewrite fan, but I think that's better than code

so IMO we should doc that interpolation isn't supported in the scheme, and 
instead a solution like that should be used

  


Regards

Rüdiger


-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Dienstag, 17. September 2013 17:26
To:dev@httpd.apache.org
Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by
regression to APR-util 1.5.2

Doesn't that completely avoid/ignore the issue in the 1st place?

On Sep 17, 2013, at 11:08 AM, Plüm, Rüdiger, Vodafone Group
ruediger.pl...@vodafone.com  wrote:


How about

  RewriteEngine On

  RewriteCond %{HTTPS} =off
  RewriteRule . - [E=protocol:http]
  RewriteCond %{HTTPS} =on
  RewriteRule . - [E=protocol:https]

  RewriteRule ^/my_app/(.*) %{protocol}://1.2.3.4/my_app/$1 [P]
  ProxyPassReverse /my_app/http://1.2.3.4/my_app/
  ProxyPassReverse /my_app/https://1.2.3.4/my_app/

?

Regards

Rüdiger

From: Jeff Trawick [mailto:traw...@gmail.com]
Sent: Dienstag, 17. September 2013 15:24
To: Apache HTTP Server Development List
Subject: Re: [PATCH 55315] mod_proxy interpolation code broken by

regression to APR-util 1.5.2

On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumphmike.ru...@oracle.com

wrote:

Hello Jeff,

Thanks for your reply.


On 9/3/2013 6:58 AM, Jeff Trawick wrote:

Since the URL validation in apr_uri_parse() has been tightened in the

handling of the scheme portion of a URL,

I submitted a patch to httpd bug 55315 against the mod_proxy code in

httpd trunk to handle the special case

of interpolating a variable in the scheme portion of a URL.

-https://issues.apache.org/bugzilla/show_bug.cgi?id=55315


Do you know if it is practical to have the one magic path down to

ap_proxy_define_worker() munge the URI?  I guess the problem is that
ap_proxy_define_worker() saves the parsed uri, and the caller (add_pass
or whatever it is) doesn't have access to that?

I take your point to be that the mod_proxy patch I submitted cannot be

applied to the branches, since it changes the API.

So I've submitted a new patch that is applied further up the stack in

add_pass() in mod_proxy.c.

That patch

(https://issues.apache.org/bugzilla/attachment.cgi?id=30799) is the one
I'm considering, as it is the one that could solve the issue for 2.2.x
(with a minor tweak) and 2.4.x (as-is), and I don't think the function
API issue is the major concern.  Instead, carrying the interpolation
expression around in the worker scheme field separate from an
interpolation flag seems to be the overriding issue.

Dynamic determination of the scheme seems very useful and I don't know

of another way to implement the same requirement, which is well
illustrated by the now-broken config in the bug:

  ProxyPassInterpolateEnv On
  RewriteEngine On

  RewriteCond %{HTTPS} =off
  RewriteRule . - [E=protocol:http]
  RewriteCond %{HTTPS} =on
  RewriteRule . - [E=protocol:https]

  ProxyPass /my_app/ ${protocol}://1.2.3.4/my_app/ interpolate
  ProxyPassReverse /my_app/ ${protocol}://1.2.3.4/my_app/

interpolate

Any alternate ideas for configuring something like that?

Otherwise, any objections to patch 30799 (URL above)?




It is interesting that my research seems to indicate that mod_proxy

interpolation was actually the first to be introduced into the code.

I guess the order is this:

1. support for environment variables in the config
2. mod_proxy interpolation
3. core server starts complaining if you have something that looks

like an envvar reference that isn't resolved

Is that what you mean?

The double use of ${} is nasty.  In the fullness of time, I think that

mod_proxy interpolation should support an additional syntax that doesn't
collide with the config-time processing.

Yes, that is the point that I was trying to make.

Thanks,

Mike Rumph



--
Born in Roswell... married an alien

[PATCH 55360] Potential buffer overflows in support/ab

[Mike Rumph]

Hello all,

A comment section in support/ab.c lists the following known problems:

/*
 * BUGS:
 *
 * - uses strcpy/etc.
 * - has various other poor buffer attacks related to the lazy parsing of
 *   response headers from the server
 * - doesn't implement much of HTTP/1.x, only accepts certain forms of
 *   responses
 * - (performance problem) heavy use of strstr shows up top in profile
 *   only an issue for loopback usage
 */

I was able to duplicate segmentation faults through the T and X command 
line options.


I submitted a patch to fix potential buffer overflows through these options.
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55360

The patch also removes 2 unreferenced fixed length buffers.

support/ab.c also contains 3 additional fixed length buffers that could 
potentially overflow:

- servername, buffer and _request

Fixing these problems will require a deeper understanding of the code.

Please, consider the submitted patch for adoption.

Thanks,

Mike Rumph

Re: 2.2.25 update for httpd.apache.org/ still stuck in staging?

[Mike Rumph]

Hello Eric,

Does this explain why the security vulnerability information for Apache 
httpd 2.2.25 has not been added to the following link?

- http://httpd.apache.org/security/vulnerabilities_22.html

Thanks,

Mike Rumph

On 7/11/2013 10:57 AM, Eric Covener wrote:

2.2.25 update for httpd.apache.org/ still stuck in staging, mentioning
since in case it's not on purpose.

--
Eric Covener
cove...@gmail.com