Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c

[Jim Jagielski]

+1. Plan for the future.

> On Jul 18, 2016, at 12:32 PM, William A Rowe Jr  wrote:
> 
> Worse, in http 2.4, the first two registered methods collide with BREW and 
> WHEN. That said, the 'fix', if we wanted to resolve it, is to use M_INVALID 
> +3 as the first value.
> 
> I suggest on trunk we use a value outside the bitmask range of 0-63 as 
> INVALID and consider turning this into an array of 128 bits. mod_ftp, for 
> examples, implents many more non-http methods and relies on the method auth 
> logic.
> 
> 
> On Jul 18, 2016 11:25 AM, "Jim Jagielski"  wrote:
> Doesn't this make this unsuitable for backport for 2.4?
> 
> > On Jul 18, 2016, at 12:20 PM, wr...@apache.org wrote:
> >
> > Author: wrowe
> > Date: Mon Jul 18 16:20:27 2016
> > New Revision: 1753263
> >
> > URL: http://svn.apache.org/viewvc?rev=1753263=rev
> > Log:
> > A whole lotta nope, if you implement HTCPCP then register your methods in 
> > init
> >
> > Modified:
> >httpd/httpd/trunk/include/httpd.h
> >httpd/httpd/trunk/modules/http/http_protocol.c
> >
> > Modified: httpd/httpd/trunk/include/httpd.h
> > URL: 
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?rev=1753263=1753262=1753263=diff
> > ==
> > --- httpd/httpd/trunk/include/httpd.h (original)
> > +++ httpd/httpd/trunk/include/httpd.h Mon Jul 18 16:20:27 2016
> > @@ -612,9 +612,15 @@ AP_DECLARE(const char *) ap_get_server_b
> > #define M_MKACTIVITY23
> > #define M_BASELINE_CONTROL  24
> > #define M_MERGE 25
> > -#define M_INVALID   26  /** no valid method */
> > -#define M_BREW  27  /** RFC 2324: HTCPCP/1.0 */
> > -#define M_WHEN  28  /** RFC 2324: HTCPCP/1.0 */
> > +/* Additional methods must be registered by the implementor, we have only
> > + * room for 64 bit-wise methods available, so do not squander them (more of
> > + * the above methods should probably move here)
> > + */
> > +/* #define M_BREW  nn */ /** RFC 2324: HTCPCP/1.0 */
> > +/* #define M_WHEN  nn */ /** RFC 2324: HTCPCP/1.0 */
> > +#define M_INVALID   26  /** invalid method value 
> > terminates the
> > + *  listed 
> > ap_method_registry_init()
> > + */
> >
> > /**
> >  * METHODS needs to be equal to the number of bits
> >
> > Modified: httpd/httpd/trunk/modules/http/http_protocol.c
> > URL: 
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_protocol.c?rev=1753263=1753262=1753263=diff
> > ==
> > --- httpd/httpd/trunk/modules/http/http_protocol.c (original)
> > +++ httpd/httpd/trunk/modules/http/http_protocol.c Mon Jul 18 16:20:27 2016
> > @@ -718,8 +718,6 @@ AP_DECLARE(void) ap_method_registry_init
> > register_one_method(p, "MKACTIVITY", M_MKACTIVITY);
> > register_one_method(p, "BASELINE-CONTROL", M_BASELINE_CONTROL);
> > register_one_method(p, "MERGE", M_MERGE);
> > -register_one_method(p, "BREW", M_BREW);
> > -register_one_method(p, "WHEN", M_WHEN);
> > }
> >
> > AP_DECLARE(int) ap_method_register(apr_pool_t *p, const char *methname)
> >
> >
> 

Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c

[William A Rowe Jr]

Worse, in http 2.4, the first two registered methods collide with BREW and
WHEN. That said, the 'fix', if we wanted to resolve it, is to use M_INVALID
+3 as the first value.

I suggest on trunk we use a value outside the bitmask range of 0-63 as
INVALID and consider turning this into an array of 128 bits. mod_ftp, for
examples, implents many more non-http methods and relies on the method auth
logic.

On Jul 18, 2016 11:25 AM, "Jim Jagielski"  wrote:

> Doesn't this make this unsuitable for backport for 2.4?
>
> > On Jul 18, 2016, at 12:20 PM, wr...@apache.org wrote:
> >
> > Author: wrowe
> > Date: Mon Jul 18 16:20:27 2016
> > New Revision: 1753263
> >
> > URL: http://svn.apache.org/viewvc?rev=1753263=rev
> > Log:
> > A whole lotta nope, if you implement HTCPCP then register your methods
> in init
> >
> > Modified:
> >httpd/httpd/trunk/include/httpd.h
> >httpd/httpd/trunk/modules/http/http_protocol.c
> >
> > Modified: httpd/httpd/trunk/include/httpd.h
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?rev=1753263=1753262=1753263=diff
> >
> ==
> > --- httpd/httpd/trunk/include/httpd.h (original)
> > +++ httpd/httpd/trunk/include/httpd.h Mon Jul 18 16:20:27 2016
> > @@ -612,9 +612,15 @@ AP_DECLARE(const char *) ap_get_server_b
> > #define M_MKACTIVITY23
> > #define M_BASELINE_CONTROL  24
> > #define M_MERGE 25
> > -#define M_INVALID   26  /** no valid method */
> > -#define M_BREW  27  /** RFC 2324: HTCPCP/1.0 */
> > -#define M_WHEN  28  /** RFC 2324: HTCPCP/1.0 */
> > +/* Additional methods must be registered by the implementor, we have
> only
> > + * room for 64 bit-wise methods available, so do not squander them
> (more of
> > + * the above methods should probably move here)
> > + */
> > +/* #define M_BREW  nn */ /** RFC 2324: HTCPCP/1.0 */
> > +/* #define M_WHEN  nn */ /** RFC 2324: HTCPCP/1.0 */
> > +#define M_INVALID   26  /** invalid method value
> terminates the
> > + *  listed
> ap_method_registry_init()
> > + */
> >
> > /**
> >  * METHODS needs to be equal to the number of bits
> >
> > Modified: httpd/httpd/trunk/modules/http/http_protocol.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_protocol.c?rev=1753263=1753262=1753263=diff
> >
> ==
> > --- httpd/httpd/trunk/modules/http/http_protocol.c (original)
> > +++ httpd/httpd/trunk/modules/http/http_protocol.c Mon Jul 18 16:20:27
> 2016
> > @@ -718,8 +718,6 @@ AP_DECLARE(void) ap_method_registry_init
> > register_one_method(p, "MKACTIVITY", M_MKACTIVITY);
> > register_one_method(p, "BASELINE-CONTROL", M_BASELINE_CONTROL);
> > register_one_method(p, "MERGE", M_MERGE);
> > -register_one_method(p, "BREW", M_BREW);
> > -register_one_method(p, "WHEN", M_WHEN);
> > }
> >
> > AP_DECLARE(int) ap_method_register(apr_pool_t *p, const char *methname)
> >
> >
>
>

Re: svn commit: r1753263 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_protocol.c

[Jim Jagielski]

Doesn't this make this unsuitable for backport for 2.4?

> On Jul 18, 2016, at 12:20 PM, wr...@apache.org wrote:
> 
> Author: wrowe
> Date: Mon Jul 18 16:20:27 2016
> New Revision: 1753263
> 
> URL: http://svn.apache.org/viewvc?rev=1753263=rev
> Log:
> A whole lotta nope, if you implement HTCPCP then register your methods in init
> 
> Modified:
>httpd/httpd/trunk/include/httpd.h
>httpd/httpd/trunk/modules/http/http_protocol.c
> 
> Modified: httpd/httpd/trunk/include/httpd.h
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?rev=1753263=1753262=1753263=diff
> ==
> --- httpd/httpd/trunk/include/httpd.h (original)
> +++ httpd/httpd/trunk/include/httpd.h Mon Jul 18 16:20:27 2016
> @@ -612,9 +612,15 @@ AP_DECLARE(const char *) ap_get_server_b
> #define M_MKACTIVITY23
> #define M_BASELINE_CONTROL  24
> #define M_MERGE 25
> -#define M_INVALID   26  /** no valid method */
> -#define M_BREW  27  /** RFC 2324: HTCPCP/1.0 */
> -#define M_WHEN  28  /** RFC 2324: HTCPCP/1.0 */
> +/* Additional methods must be registered by the implementor, we have only
> + * room for 64 bit-wise methods available, so do not squander them (more of
> + * the above methods should probably move here)
> + */
> +/* #define M_BREW  nn */ /** RFC 2324: HTCPCP/1.0 */
> +/* #define M_WHEN  nn */ /** RFC 2324: HTCPCP/1.0 */
> +#define M_INVALID   26  /** invalid method value terminates 
> the
> + *  listed ap_method_registry_init()
> + */
> 
> /**
>  * METHODS needs to be equal to the number of bits
> 
> Modified: httpd/httpd/trunk/modules/http/http_protocol.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_protocol.c?rev=1753263=1753262=1753263=diff
> ==
> --- httpd/httpd/trunk/modules/http/http_protocol.c (original)
> +++ httpd/httpd/trunk/modules/http/http_protocol.c Mon Jul 18 16:20:27 2016
> @@ -718,8 +718,6 @@ AP_DECLARE(void) ap_method_registry_init
> register_one_method(p, "MKACTIVITY", M_MKACTIVITY);
> register_one_method(p, "BASELINE-CONTROL", M_BASELINE_CONTROL);
> register_one_method(p, "MERGE", M_MERGE);
> -register_one_method(p, "BREW", M_BREW);
> -register_one_method(p, "WHEN", M_WHEN);
> }
> 
> AP_DECLARE(int) ap_method_register(apr_pool_t *p, const char *methname)
> 
> 

Re: Multiple test framework errors on trunk

[William A Rowe Jr]

See
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_script.c?r1=1747469=1751138_format=h

On Mon, Jul 18, 2016 at 10:17 AM, Jim Jagielski  wrote:

> On OSX 10.11.5 (Xcode 7.3.x), I am getting multiple errors on trunk,
> with clear sailing on httpd-2.4
>
> Test errors are for t/apache/etags.t, t/modules/expires.t and
> t/modules/headers.t
>
> Sample verbose output below:
>
> # ---
> # ExpiresActive On
> ExpiresDefault "modification plus 16 days 43 minutes 15 seconds"
> ExpiresByType image/gif A6841384
> # debug: [Connection] [close]
> # debug: [Date] [Mon, 18 Jul 2016 15:12:48 GMT]
> # debug: [Server] [Apache/2.5.0-dev (Unix) OpenSSL/1.0.2h]
> # debug: [Allow] [GET,HEAD,POST,OPTIONS,TRACE]
> # debug: [Content-Length] [224]
> # debug: [Content-Type] [text/html; charset=iso-8859-1]
> # debug: [Client-Date] [Mon, 18 Jul 2016 15:12:48 GMT]
> # debug: [Client-Peer] [127.0.0.1:8529]
> # debug: [Client-Response-Num] [1]
> # debug: modified
> # debug: modified 0
> # debug: access Mon, 18 Jul 2016 15:12:48 GMT
> # debug: access 1468854768
> # debug: expires
> # debug: expires 0
> # debug: expected: 1468854768
> # debug: actual  : 0
> not ok 40
> # Failed test 40 in t/modules/expires.t at line 125 fail #8
> #---
> # ExpiresActive On
> ExpiresDefault A35597723
> # debug: [Connection] [close]
> # debug: [Date] [Mon, 18 Jul 2016 15:12:48 GMT]
> # debug: [Server] [Apache/2.5.0-dev (Unix) OpenSSL/1.0.2h]
> # debug: [Allow] [GET,HEAD,POST,OPTIONS,TRACE]
> # debug: [Content-Length] [227]
> # debug: [Content-Type] [text/html; charset=iso-8859-1]
> # debug: [Client-Date] [Mon, 18 Jul 2016 15:12:48 GMT]
> # debug: [Client-Peer] [127.0.0.1:8529]
> # debug: [Client-Response-Num] [1]
> # debug: modified
> # debug: modified 0
> # debug: access Mon, 18 Jul 2016 15:12:48 GMT
> # debug: access 1468854768
> # debug: expires
> # debug: expires 0
> # debug: expected: 35597723
> # debug: actual  : -1468854768
> not ok 41
> # Failed test 41 in t/modules/expires.t at line 93 fail #9
>

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

[Jim Jagielski]

Beat me to the patch... :)

> On Jul 18, 2016, at 12:02 PM, William A Rowe Jr  wrote:
> 
> On Mon, Jul 18, 2016 at 11:00 AM, Jim Jagielski  wrote:
> Hrm. ap_method_registry_init lacks HEAD
> 
> And has no M_HEAD, it's M_GET. Resolved, reviewing the zany bytewise
> logic for any other missing identifiers.
> 
> Thanks for the catch. 
> 

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

[William A Rowe Jr]

On Mon, Jul 18, 2016 at 11:00 AM, Jim Jagielski  wrote:

> Hrm. ap_method_registry_init lacks HEAD


And has no M_HEAD, it's M_GET. Resolved, reviewing the zany bytewise
logic for any other missing identifiers.

Thanks for the catch.

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

[Jim Jagielski]

I am getting NUMEROUS errors on trunk... HEAD is returning 501. The
only test where this does NOT occur is:

"HEAD /modules/cgi/perl.pl HTTP/1.1" 200 8

Looks suspicious to me...


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

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

[Jim Jagielski]

Hrm. ap_method_registry_init lacks HEAD.

> On Jul 18, 2016, at 11:57 AM, William A Rowe Jr  wrote:
> 
> Investigating, should have it clearer w/in 1/2 an hr
> 
> 
> On Jul 18, 2016 10:54 AM, "Jim Jagielski"  wrote:
> I am getting NUMEROUS errors on trunk... HEAD is returning 501. The
> only test where this does NOT occur is:
> 
> "HEAD /modules/cgi/perl.pl HTTP/1.1" 200 8
> 
> Looks suspicious to me...
> 
> 
> > On Jul 18, 2016, at 11:44 AM, Rüdiger Plüm  wrote:
> >
> >
> >
> > On 07/18/2016 05:28 PM, William A Rowe Jr wrote:
> >> On Mon, Jul 18, 2016 at 10:22 AM, Ruediger Pluem  >> > wrote:
> >>
> >>
> >>On 07/18/2016 03:41 PM, wr...@apache.org  
> >> wrote:
> >>> Author: wrowe
> >>> Date: Mon Jul 18 13:41:26 2016
> >>> New Revision: 1753223
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1753223=rev
> >>> Log:
> >>> Simplify; this code is executed one per request processed, saving
> >>> an immeasurably small quantum of CPU of a server under load.
> >>>
> >>> +int *methnum = apr_hash_get(methods_registry, method, len);
> >>
> >>How do we ensure that methods_registry is not NULL or better that
> >>ap_method_registry_init was called before?
> >>
> >>
> >> Is the ap_method_registry_init in mod_http register_hooks() insufficient?
> >>
> >>
> >>
> >
> > Doh. I missed that. Sorry for the noise.
> >
> > Regards
> >
> > Rüdiger
> 

Re: Multiple test framework errors on trunk

[Jim Jagielski]

[Mon Jul 18 15:57:00.513202 2016] [core:error] [pid 6239:tid 123145317863424] 
[client 127.0.0.1:60655] AH00135: Invalid method in request HEAD 
/apache/etags/none/plus-mis/minus-ms/test.txt HTTP/1.1

> On Jul 18, 2016, at 11:55 AM, Jim Jagielski  wrote:
> 
> In fact, ALL HEADs are returning 501, except for this single one:
> 
>   "HEAD /modules/cgi/perl.pl HTTP/1.1" 200 8
> 
> 

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

[Jim Jagielski]

[Mon Jul 18 15:57:00.513202 2016] [core:error] [pid 6239:tid 123145317863424] 
[client 127.0.0.1:60655] AH00135: Invalid method in request HEAD 
/apache/etags/none/plus-mis/minus-ms/test.txt HTTP/1.1

> On Jul 18, 2016, at 11:57 AM, William A Rowe Jr  wrote:
> 
> Investigating, should have it clearer w/in 1/2 an hr
> 
> 
> On Jul 18, 2016 10:54 AM, "Jim Jagielski"  wrote:
> I am getting NUMEROUS errors on trunk... HEAD is returning 501. The
> only test where this does NOT occur is:
> 
> "HEAD /modules/cgi/perl.pl HTTP/1.1" 200 8
> 
> Looks suspicious to me...
> 
> 
> > On Jul 18, 2016, at 11:44 AM, Rüdiger Plüm  wrote:
> >
> >
> >
> > On 07/18/2016 05:28 PM, William A Rowe Jr wrote:
> >> On Mon, Jul 18, 2016 at 10:22 AM, Ruediger Pluem  >> > wrote:
> >>
> >>
> >>On 07/18/2016 03:41 PM, wr...@apache.org  
> >> wrote:
> >>> Author: wrowe
> >>> Date: Mon Jul 18 13:41:26 2016
> >>> New Revision: 1753223
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1753223=rev
> >>> Log:
> >>> Simplify; this code is executed one per request processed, saving
> >>> an immeasurably small quantum of CPU of a server under load.
> >>>
> >>> +int *methnum = apr_hash_get(methods_registry, method, len);
> >>
> >>How do we ensure that methods_registry is not NULL or better that
> >>ap_method_registry_init was called before?
> >>
> >>
> >> Is the ap_method_registry_init in mod_http register_hooks() insufficient?
> >>
> >>
> >>
> >
> > Doh. I missed that. Sorry for the noise.
> >
> > Regards
> >
> > Rüdiger
> 

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

[William A Rowe Jr]

Investigating, should have it clearer w/in 1/2 an hr

On Jul 18, 2016 10:54 AM, "Jim Jagielski"  wrote:

> I am getting NUMEROUS errors on trunk... HEAD is returning 501. The
> only test where this does NOT occur is:
>
> "HEAD /modules/cgi/perl.pl HTTP/1.1" 200 8
>
> Looks suspicious to me...
>
>
> > On Jul 18, 2016, at 11:44 AM, Rüdiger Plüm  wrote:
> >
> >
> >
> > On 07/18/2016 05:28 PM, William A Rowe Jr wrote:
> >> On Mon, Jul 18, 2016 at 10:22 AM, Ruediger Pluem  > wrote:
> >>
> >>
> >>On 07/18/2016 03:41 PM, wr...@apache.org 
> wrote:
> >>> Author: wrowe
> >>> Date: Mon Jul 18 13:41:26 2016
> >>> New Revision: 1753223
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1753223=rev
> >>> Log:
> >>> Simplify; this code is executed one per request processed, saving
> >>> an immeasurably small quantum of CPU of a server under load.
> >>>
> >>> +int *methnum = apr_hash_get(methods_registry, method, len);
> >>
> >>How do we ensure that methods_registry is not NULL or better that
> >>ap_method_registry_init was called before?
> >>
> >>
> >> Is the ap_method_registry_init in mod_http register_hooks()
> insufficient?
> >>
> >>
> >>
> >
> > Doh. I missed that. Sorry for the noise.
> >
> > Regards
> >
> > Rüdiger
>
>

Re: Multiple test framework errors on trunk

[Jim Jagielski]

In fact, ALL HEADs are returning 501, except for this single one:

   "HEAD /modules/cgi/perl.pl HTTP/1.1" 200 8

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

[Rüdiger Plüm]

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

Doh. I missed that. Sorry for the noise.

Regards

Rüdiger

Re: Multiple test framework errors on trunk

[Jim Jagielski]

For the etags test, fails are due to 501 errors:

   127.0.0.1 - - [18/Jul/2016:15:41:37 +] "HEAD 
/apache/etags/none/plus-mis/minus-s/test.txt HTTP/1.1" 501 235
   127.0.0.1 - - [18/Jul/2016:15:41:37 +] "HEAD 
/apache/etags/none/plus-mis/minus-mi/test.txt HTTP/1.1" 501 236
   127.0.0.1 - - [18/Jul/2016:15:41:37 +] "HEAD /apache/etags/ms/test.txt 
HTTP/1.1" 501 216
   127.0.0.1 - - [18/Jul/2016:15:41:37 +] "HEAD 
/apache/etags/all/minus-mi/test.txt HTTP/1.1" 501 226
   127.0.0.1 - - [18/Jul/2016:15:41:37 +] "HEAD 
/apache/etags/none/plus-mis/minus-ms/test.txt HTTP/1.1" 501 236
   127.0.0.1 - - [18/Jul/2016:15:41:37 +] "HEAD 
/apache/etags/m/plus-s/test.txt HTTP/1.1" 501 222

# HEAD /apache/etags/i/test.txt
# Expecting one component in ETag field
# Failed test 59 in t/apache/etags.t at line 160 fail #48
# ETag field is missing
# ETag field was expected
not ok 60
# ---
# HEAD /apache/etags/none/plus-is/test.txt
# Expecting two components in ETag field
# Failed test 60 in t/apache/etags.t at line 160 fail #49
# ETag field is missing
# ETag field was expected
not ok 61
# Failed test 61 in t/apache/etags.t at line 160 fail #50

Looks like the same w/ headers too... lots of 501s :(

> On Jul 18, 2016, at 11:31 AM, Jim Jagielski  wrote:
> 
> On CentOS6 as well. Obviously, either something is hosed on
> trunk or something has changed and the test framework has not
> been updated...
> 
>> On Jul 18, 2016, at 11:17 AM, Jim Jagielski  wrote:
>> 
>> On OSX 10.11.5 (Xcode 7.3.x), I am getting multiple errors on trunk,
>> with clear sailing on httpd-2.4
>> 
>> Test errors are for t/apache/etags.t, t/modules/expires.t and
>> t/modules/headers.t
>> 
>> Sample verbose output below:
>> 
>> # ---
>> # ExpiresActive On
>> ExpiresDefault "modification plus 16 days 43 minutes 15 seconds"
>> ExpiresByType image/gif A6841384
>> # debug: [Connection] [close]
>> # debug: [Date] [Mon, 18 Jul 2016 15:12:48 GMT]
>> # debug: [Server] [Apache/2.5.0-dev (Unix) OpenSSL/1.0.2h]
>> # debug: [Allow] [GET,HEAD,POST,OPTIONS,TRACE]
>> # debug: [Content-Length] [224]
>> # debug: [Content-Type] [text/html; charset=iso-8859-1]
>> # debug: [Client-Date] [Mon, 18 Jul 2016 15:12:48 GMT]
>> # debug: [Client-Peer] [127.0.0.1:8529]
>> # debug: [Client-Response-Num] [1]
>> # debug: modified
>> # debug: modified 0
>> # debug: access Mon, 18 Jul 2016 15:12:48 GMT
>> # debug: access 1468854768
>> # debug: expires
>> # debug: expires 0
>> # debug: expected: 1468854768
>> # debug: actual  : 0
>> not ok 40
>> # Failed test 40 in t/modules/expires.t at line 125 fail #8
>> #---
>> # ExpiresActive On
>> ExpiresDefault A35597723
>> # debug: [Connection] [close]
>> # debug: [Date] [Mon, 18 Jul 2016 15:12:48 GMT]
>> # debug: [Server] [Apache/2.5.0-dev (Unix) OpenSSL/1.0.2h]
>> # debug: [Allow] [GET,HEAD,POST,OPTIONS,TRACE]
>> # debug: [Content-Length] [227]
>> # debug: [Content-Type] [text/html; charset=iso-8859-1]
>> # debug: [Client-Date] [Mon, 18 Jul 2016 15:12:48 GMT]
>> # debug: [Client-Peer] [127.0.0.1:8529]
>> # debug: [Client-Response-Num] [1]
>> # debug: modified
>> # debug: modified 0
>> # debug: access Mon, 18 Jul 2016 15:12:48 GMT
>> # debug: access 1468854768
>> # debug: expires
>> # debug: expires 0
>> # debug: expected: 35597723
>> # debug: actual  : -1468854768
>> not ok 41
>> # Failed test 41 in t/modules/expires.t at line 93 fail #9
> 

Re: Multiple test framework errors on trunk

[Jim Jagielski]

On CentOS6 as well. Obviously, either something is hosed on
trunk or something has changed and the test framework has not
been updated...

> On Jul 18, 2016, at 11:17 AM, Jim Jagielski  wrote:
> 
> On OSX 10.11.5 (Xcode 7.3.x), I am getting multiple errors on trunk,
> with clear sailing on httpd-2.4
> 
> Test errors are for t/apache/etags.t, t/modules/expires.t and
> t/modules/headers.t
> 
> Sample verbose output below:
> 
> # ---
> # ExpiresActive On
> ExpiresDefault "modification plus 16 days 43 minutes 15 seconds"
> ExpiresByType image/gif A6841384
> # debug: [Connection] [close]
> # debug: [Date] [Mon, 18 Jul 2016 15:12:48 GMT]
> # debug: [Server] [Apache/2.5.0-dev (Unix) OpenSSL/1.0.2h]
> # debug: [Allow] [GET,HEAD,POST,OPTIONS,TRACE]
> # debug: [Content-Length] [224]
> # debug: [Content-Type] [text/html; charset=iso-8859-1]
> # debug: [Client-Date] [Mon, 18 Jul 2016 15:12:48 GMT]
> # debug: [Client-Peer] [127.0.0.1:8529]
> # debug: [Client-Response-Num] [1]
> # debug: modified
> # debug: modified 0
> # debug: access Mon, 18 Jul 2016 15:12:48 GMT
> # debug: access 1468854768
> # debug: expires
> # debug: expires 0
> # debug: expected: 1468854768
> # debug: actual  : 0
> not ok 40
> # Failed test 40 in t/modules/expires.t at line 125 fail #8
> #---
> # ExpiresActive On
> ExpiresDefault A35597723
> # debug: [Connection] [close]
> # debug: [Date] [Mon, 18 Jul 2016 15:12:48 GMT]
> # debug: [Server] [Apache/2.5.0-dev (Unix) OpenSSL/1.0.2h]
> # debug: [Allow] [GET,HEAD,POST,OPTIONS,TRACE]
> # debug: [Content-Length] [227]
> # debug: [Content-Type] [text/html; charset=iso-8859-1]
> # debug: [Client-Date] [Mon, 18 Jul 2016 15:12:48 GMT]
> # debug: [Client-Peer] [127.0.0.1:8529]
> # debug: [Client-Response-Num] [1]
> # debug: modified
> # debug: modified 0
> # debug: access Mon, 18 Jul 2016 15:12:48 GMT
> # debug: access 1468854768
> # debug: expires
> # debug: expires 0
> # debug: expected: 35597723
> # debug: actual  : -1468854768
> not ok 41
> # Failed test 41 in t/modules/expires.t at line 93 fail #9

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

[William A Rowe Jr]

On Mon, Jul 18, 2016 at 10:22 AM, Ruediger Pluem  wrote:

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

Is the ap_method_registry_init in mod_http register_hooks() insufficient?

Multiple test framework errors on trunk

[Jim Jagielski]

On OSX 10.11.5 (Xcode 7.3.x), I am getting multiple errors on trunk,
with clear sailing on httpd-2.4

Test errors are for t/apache/etags.t, t/modules/expires.t and
t/modules/headers.t

Sample verbose output below:

# ---
# ExpiresActive On
ExpiresDefault "modification plus 16 days 43 minutes 15 seconds"
ExpiresByType image/gif A6841384
# debug: [Connection] [close]
# debug: [Date] [Mon, 18 Jul 2016 15:12:48 GMT]
# debug: [Server] [Apache/2.5.0-dev (Unix) OpenSSL/1.0.2h]
# debug: [Allow] [GET,HEAD,POST,OPTIONS,TRACE]
# debug: [Content-Length] [224]
# debug: [Content-Type] [text/html; charset=iso-8859-1]
# debug: [Client-Date] [Mon, 18 Jul 2016 15:12:48 GMT]
# debug: [Client-Peer] [127.0.0.1:8529]
# debug: [Client-Response-Num] [1]
# debug: modified
# debug: modified 0
# debug: access Mon, 18 Jul 2016 15:12:48 GMT
# debug: access 1468854768
# debug: expires
# debug: expires 0
# debug: expected: 1468854768
# debug: actual  : 0
not ok 40
# Failed test 40 in t/modules/expires.t at line 125 fail #8
#---
# ExpiresActive On
ExpiresDefault A35597723
# debug: [Connection] [close]
# debug: [Date] [Mon, 18 Jul 2016 15:12:48 GMT]
# debug: [Server] [Apache/2.5.0-dev (Unix) OpenSSL/1.0.2h]
# debug: [Allow] [GET,HEAD,POST,OPTIONS,TRACE]
# debug: [Content-Length] [227]
# debug: [Content-Type] [text/html; charset=iso-8859-1]
# debug: [Client-Date] [Mon, 18 Jul 2016 15:12:48 GMT]
# debug: [Client-Peer] [127.0.0.1:8529]
# debug: [Client-Response-Num] [1]
# debug: modified
# debug: modified 0
# debug: access Mon, 18 Jul 2016 15:12:48 GMT
# debug: access 1468854768
# debug: expires
# debug: expires 0
# debug: expected: 35597723
# debug: actual  : -1468854768
not ok 41
# Failed test 41 in t/modules/expires.t at line 93 fail #9

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

[Ruediger Pluem]

On 07/18/2016 03:41 PM, wr...@apache.org wrote:
> Author: wrowe
> Date: Mon Jul 18 13:41:26 2016
> New Revision: 1753223
> 
> URL: http://svn.apache.org/viewvc?rev=1753223=rev
> Log:
> Simplify; this code is executed one per request processed, saving 
> an immeasurably small quantum of CPU of a server under load.
> 
> Modified:
> httpd/httpd/trunk/modules/http/http_protocol.c
> 
> Modified: httpd/httpd/trunk/modules/http/http_protocol.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_protocol.c?rev=1753223=1753222=1753223=diff
> ==
> --- httpd/httpd/trunk/modules/http/http_protocol.c (original)
> +++ httpd/httpd/trunk/modules/http/http_protocol.c Mon Jul 18 13:41:26 2016
> @@ -754,193 +754,6 @@ AP_DECLARE(int) ap_method_register(apr_p
>  return cur_method_number++;
>  }
>  
> -#define UNKNOWN_METHOD (-1)
> -
> -static int lookup_builtin_method(const char *method, apr_size_t len)
> -{
> -/* Note: the following code was generated by the "shilka" tool from
> -   the "cocom" parsing/compilation toolkit. It is an optimized lookup
> -   based on analysis of the input keywords. Postprocessing was done
> -   on the shilka output, but the basic structure and analysis is
> -   from there. Should new HTTP methods be added, then manual insertion
> -   into this code is fine, or simply re-running the shilka tool on
> -   the appropriate input. */
> -
> -/* Note: it is also quite reasonable to just use our method_registry,
> -   but I'm assuming (probably incorrectly) we want more speed here
> -   (based on the optimizations the previous code was doing). */
> -
> -switch (len)
> -{
> -case 3:
> -switch (method[0])
> -{
> -case 'P':
> -return (method[1] == 'U'
> -&& method[2] == 'T'
> -? M_PUT : UNKNOWN_METHOD);
> -case 'G':
> -return (method[1] == 'E'
> -&& method[2] == 'T'
> -? M_GET : UNKNOWN_METHOD);
> -default:
> -return UNKNOWN_METHOD;
> -}
> -
> -case 4:
> -switch (method[0])
> -{
> -case 'H':
> -return (method[1] == 'E'
> -&& method[2] == 'A'
> -&& method[3] == 'D'
> -? M_GET : UNKNOWN_METHOD);
> -case 'P':
> -return (method[1] == 'O'
> -&& method[2] == 'S'
> -&& method[3] == 'T'
> -? M_POST : UNKNOWN_METHOD);
> -case 'M':
> -return (method[1] == 'O'
> -&& method[2] == 'V'
> -&& method[3] == 'E'
> -? M_MOVE : UNKNOWN_METHOD);
> -case 'L':
> -return (method[1] == 'O'
> -&& method[2] == 'C'
> -&& method[3] == 'K'
> -? M_LOCK : UNKNOWN_METHOD);
> -case 'C':
> -return (method[1] == 'O'
> -&& method[2] == 'P'
> -&& method[3] == 'Y'
> -? M_COPY : UNKNOWN_METHOD);
> -case 'B':
> -return (method[1] == 'R'
> -&& method[2] == 'E'
> -&& method[3] == 'W'
> -? M_BREW : UNKNOWN_METHOD);
> -case 'W':
> -return (method[1] == 'H'
> -&& method[2] == 'E'
> -&& method[3] == 'N'
> -? M_WHEN : UNKNOWN_METHOD);
> -default:
> -return UNKNOWN_METHOD;
> -}
> -
> -case 5:
> -switch (method[2])
> -{
> -case 'T':
> -return (memcmp(method, "PATCH", 5) == 0
> -? M_PATCH : UNKNOWN_METHOD);
> -case 'R':
> -return (memcmp(method, "MERGE", 5) == 0
> -? M_MERGE : UNKNOWN_METHOD);
> -case 'C':
> -return (memcmp(method, "MKCOL", 5) == 0
> -? M_MKCOL : UNKNOWN_METHOD);
> -case 'B':
> -return (memcmp(method, "LABEL", 5) == 0
> -? M_LABEL : UNKNOWN_METHOD);
> -case 'A':
> -return (memcmp(method, "TRACE", 5) == 0
> -? M_TRACE : UNKNOWN_METHOD);
> -default:
> -return UNKNOWN_METHOD;
> -}
> -
> -case 6:
> -switch (method[0])
> -{
> -case 'U':
> -switch (method[5])
> -{
> -case 'K':
> -return (memcmp(method, "UNLOCK", 6) == 0
> -? M_UNLOCK : UNKNOWN_METHOD);
> -case 'E':
> -return (memcmp(method, "UPDATE", 6) == 0
> -? M_UPDATE : UNKNOWN_METHOD);
> -default:
> -return UNKNOWN_METHOD;
> -}
> -

[Advisory] Apache Software Foundation Projects and "httpoxy" CERT VU#797896

[William A Rowe Jr]

Advisory: Apache Software Foundation Projects and "httpoxy" CERT VU#797896

Canonical URL: https://www.apache.org/security/asf-httpoxy-response.txt

Publication: v1.0  18 July 2016


Audience


This Advisory is directed to HTTP web server administrators and users of
the software indicated below, including CGI developers.

This Advisory is not directed to a general audience, especially web browser
users. The issues raised by the "httpoxy" class of vulnerabilities affect
web servers, and are not an issue for consumers of web services to address.


Background
--

The ASF (Apache Software Foundation) offers a number of software packages
which offer HTTP protocol ("Web") requests and responses, and offer the
developer or admininstrator CGI (Common Gateway Interface) routing through
these software packages.

The Apache HTTP Server (httpd and mod_fcgid), Apache Perl (mod_perl) and
Apache Tomcat projects all offer CGI handling of HTTP requests.

The Apache Traffic Server proxies HTTP requests, but offers no CGI support.

Many other ASF projects utilize the HTTP protocol, but at this time we have
not identified any which provide CGI handling, or forward the HTTP "Proxy:"
header implicated in the "httpoxy" class of issues. In the event that other
projects discover such a defect, or can contribute to mitigating this class
of issues, this Advisory will be updated.

Note especially that PHP (http://www.php.net) is not an Apache Software
Foundation project (this is a common point of confusion), and that this
Advisory does not attempt to address third-party software, scripts,
libraries or components affected by the "httpoxy" group of issues.

See https://httpoxy.org/ (not affiliated with the ASF) for a complete
discussion of the "httpoxy" class of issues, which are not reiterated
in this advisory.

The Apache Software Foundation wishes to thank Dominic Scheirlinck
and Scott Geary of Vend for bringing this issue to the attention of
the ASF Security Team for a well-coordinated community response.


Apache HTTP Server (httpd)
--

Apache HTTP Server may be configured to proxy HTTP requests as a forward
or reverse (gateway) proxy server, can proxy requests to a FastCGI service
using mod_proxy_fcgi, can directly serve CGI applications using mod_cgi
or mod_cgid or the related mod_isapi service. The project's mod_fcgid
subproject (available as a separate add-in module) directly manages CGI
scripts using the FastCGI protocol.

It may also be configured to directly host a number of external modules
which run CGI-style applications in-process. The server itself does not
modify the CGI environment in this case, however, these external modules
may perform such modifications of their environment variables in-process.
Such examples include mod_php, mod_perl and mod_wsgi.

To mitigate "httpoxy" issues across all of the above mechanisms, the most
direct solution is to drop any "Proxy:" header arriving from an upstream
proxy server or the origin user-agent. this will mitigate the issue for any
vulnerable back-end server or CGI across all traffic through this server.

The two lines below enabled in the httpd.conf file will remove the "Proxy:"
header from all incoming requests, before further processing;

LoadModule headers_module {path-to}/mod_headers.so

RequestHeader unset Proxy early

(Users who have mod_headers compiled-in to the httpd binary must omit
the LoadModule directive above, others must adjust the {path-to} to point
to the mod_headers.so file.)

If the administrator wishes to preserve the value of the "Proxy:" header
for most traffic, and only eliminate it from the CGI environment variable
HTTP_PROXY, a second mitigation is offered. This patch will address this
behavior in mod_cgi, mod_cgid, mod_isapi, mod_proxy_fcgi and mod_fcgid,
along with all other consumers of httpd's built-in environment handling.

The bundled httpd modules all rely on ap_add_common_vars() to set up the
target CGI environment. The project will include the recommended patch
below in all subsequent releases of httpd, including 2.4.24 and 2.2.32.
Users who build httpd 2.2.x or 2.4.x from source may apply the patch below,
recompile and re-install httpd to obtain this mitigation. This migitation
has been assigned the identifier CVE-2016-5387 .

=== Patch to httpd sources 2.4.x and 2.2.x ===
--- server/util_script.c(revision 1752426)
+++ server/util_script.c(working copy)
@@ -186,6 +186,14 @@ AP_DECLARE(void) ap_add_common_vars(request_rec *r
 else if (!strcasecmp(hdrs[i].key, "Content-length")) {
 apr_table_addn(e, "CONTENT_LENGTH", hdrs[i].val);
 }
+/* HTTP_PROXY collides with a popular envvar used to configure
+ * proxies, don't let clients set/override it.  But, if you must...
+ */
+#ifndef SECURITY_HOLE_PASS_PROXY
+else if (!strcasecmp(hdrs[i].key, "Proxy")) {
+;
+}
+#endif
 

Re: svn commit: r1753167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_fcgi.c

[Luca Toscano]

2016-07-18 10:54 GMT+02:00 Ruediger Pluem :

Hi Ruediger,


>
> On 07/18/2016 10:02 AM, elu...@apache.org wrote:
> > Author: elukey
> > Date: Mon Jul 18 08:02:23 2016
> > New Revision: 1753167
> >
> > URL: http://svn.apache.org/viewvc?rev=1753167=rev
> > Log:
> > mod_proxy_fcgi: avoid loops serving proxied error documents
> >
> > This commit should solve the issue indicated in PR 55415.
> > Httpd loops while serving a error document if:
> > 1) The error document's content is proxied.
> > 2) ProxyErrorOverride is set.
> > The solution proposed is to limit the use of ap_die only
> > to the initial request. I tested the change with very basic
> > scenarios but I am not sure if I got all the use cases,
> > feedback is really welcome.
> >
> >
>
> Does this only affect mod_proxy_fcgi or does it affect the other proxy
> modules as well?
>

the bugzilla report was only for mod_proxy_fcgi. I checked mod_proxy_http
and the issue has already been fixed in the past (in a different way since
it doesn't use ap_die at all afaiu). I am not sure about all the proxy
modules but we could make a quick check to all of them.

Regards,

Luca

Re: svn commit: r1753167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_fcgi.c

[Ruediger Pluem]

On 07/18/2016 10:02 AM, elu...@apache.org wrote:
> Author: elukey
> Date: Mon Jul 18 08:02:23 2016
> New Revision: 1753167
> 
> URL: http://svn.apache.org/viewvc?rev=1753167=rev
> Log:
> mod_proxy_fcgi: avoid loops serving proxied error documents
> 
> This commit should solve the issue indicated in PR 55415.
> Httpd loops while serving a error document if:
> 1) The error document's content is proxied.
> 2) ProxyErrorOverride is set.
> The solution proposed is to limit the use of ap_die only
> to the initial request. I tested the change with very basic
> scenarios but I am not sure if I got all the use cases,
> feedback is really welcome.
> 
> 

Does this only affect mod_proxy_fcgi or does it affect the other proxy modules 
as well?

Regards

Rüdiger