Re: svn commit: r1523974 - in /httpd/httpd/branches/2.4.x: docs/manual/mod/mod_lua.xml modules/lua/lua_request.c modules/lua/mod_lua.c

2013-09-17 Thread Yann Ylavic
On Tue, Sep 17, 2013 at 12:38 PM, wrote: > Author: humbedooh > Date: Tue Sep 17 10:38:12 2013 > New Revision: 1523974 > > <...> > > > +static apr_uint64_t ap_ntoh64(const apr_uint64_t *input) > +{ > +apr_uint64_t rval; > +unsigned char *data = (unsigned char *)&rval; > + > +data[0] =

Re: svn commit: r1524161 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/http/http_filters.c server/protocol.c

2013-09-17 Thread Yann Ylavic
The following patch seems to be "draft-ietf-httpbis-p1-messaging-23, section 3.3.3.3" compliant (unlike current code) : Index: server/protocol.c === --- server/protocol.c(revision 1524231) +++ server/protocol.c(working copy)

Re: svn commit: r1524161 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/http/http_filters.c server/protocol.c

2013-09-17 Thread Yann Ylavic
On Tue, Sep 17, 2013 at 10:52 PM, Yann Ylavic wrote: > On Tue, Sep 17, 2013 at 10:42 PM, Yann Ylavic wrote: > >> On Tue, Sep 17, 2013 at 9:34 PM, Jim Jagielski wrote: >> >>> Ahh... So none of this is really needed then. At least, it should >>> be reverted. >>> >>> >> Well, as I understand the "n

Re: svn commit: r1524161 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/http/http_filters.c server/protocol.c

2013-09-17 Thread Yann Ylavic
On Tue, Sep 17, 2013 at 9:34 PM, Jim Jagielski wrote: > Ahh... So none of this is really needed then. At least, it should > be reverted. > > Well, as I understand the "new rfc", the old code is broken too. However, the fix should not continue with the content-length (if any) when the transfer-en

Re: svn commit: r1524161 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/http/http_filters.c server/protocol.c

2013-09-17 Thread Yann Ylavic
On Tue, Sep 17, 2013 at 10:42 PM, Yann Ylavic wrote: > On Tue, Sep 17, 2013 at 9:34 PM, Jim Jagielski wrote: > >> Ahh... So none of this is really needed then. At least, it should >> be reverted. >> >> > Well, as I understand the "new rfc", the old code is broken too. > > However, the fix should

Re: svn commit: r1524161 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/http/http_filters.c server/protocol.c

2013-09-17 Thread Jim Jagielski
Ahh... So none of this is really needed then. At least, it should be reverted. On Sep 17, 2013, at 3:10 PM, "Roy T. Fielding" wrote: > Umm, 2616 hasn't been the spec-of-record for HTTP/1.1 for almost > six years. The current spec says > > If a Transfer-Encoding header field > is pr

Re: In what situations is mod_allowmethods preferable to Require method?

2013-09-17 Thread William A. Rowe Jr.
On Mon, 16 Sep 2013 10:11:38 -0400 Jeff Trawick wrote: > Thanks! IIRC the justification for mod_allowmethods to overlap with the existing functionality was for mass vhosting, but some of the http://*.apache.org architects could provide a more complete answer.

Re: svn commit: r1524161 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/http/http_filters.c server/protocol.c

2013-09-17 Thread Roy T. Fielding
Umm, 2616 hasn't been the spec-of-record for HTTP/1.1 for almost six years. The current spec says If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliabl

Re: svn commit: r1524101 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c

2013-09-17 Thread Jim Jagielski
Nice. Might as well also note if they are inherited as well...? On Sep 17, 2013, at 11:46 AM, drugg...@apache.org wrote: > Author: druggeri > Date: Tue Sep 17 15:46:56 2013 > New Revision: 1524101 > > URL: http://svn.apache.org/r1524101 > Log: > Add note to balancer manager whether changes will/

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

2013-09-17 Thread Jim Jagielski
+1 On Sep 17, 2013, at 11:32 AM, Jeff Trawick wrote: > On Tue, Sep 17, 2013 at 11:30 AM, Plüm, Rüdiger, Vodafone Group > 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

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

2013-09-17 Thread Jeff Trawick
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 inst

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

2013-09-17 Thread Plüm , Rüdiger , Vodafone Group
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/ h

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

2013-09-17 Thread Plüm , Rüdiger , Vodafone Group
IMHO yes. But I am a mod_rewrite fan anyway :-). 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

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

2013-09-17 Thread Jim Jagielski
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" wrote: > How about > > RewriteEngine On > > RewriteCond %{HTTPS} =off > RewriteRule . - [E=protocol:http] > RewriteCond %{HTTPS} =on > Rewr

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

2013-09-17 Thread Jim Jagielski
Would it also make sense to put that info into r->notes ? On Sep 17, 2013, at 9:23 AM, Jeff Trawick wrote: > On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph 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(

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

2013-09-17 Thread Jeff Trawick
On Wed, Sep 4, 2013 at 5:12 PM, Mike Rumph 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 553