Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

Looks good to me. Can you commit this, then I quickly run my tests with it... > Am 28.06.2016 um 09:50 schrieb Yann Ylavic : > > On Tue, Jun 28, 2016 at 12:23 AM, Yann Ylavic wrote: >>> >>> The possible issue if r1750414 were backported, is that

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

On Tue, Jun 28, 2016 at 12:23 AM, Yann Ylavic wrote: >> >> The possible issue if r1750414 were backported, is that without >> r1750392 mod_proxy_http2 may not detect a TLS close notify before >> reusing a backend connection. >> If it's not backported, it may close a

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

I can, but is mod_proxy_h2 CTR (Commit Then Review) like mod_h2 ? On Tue, Jun 28, 2016 at 12:15 PM, Stefan Eissing wrote: > Looks good to me. Can you commit this, then I quickly run my tests with it... > >> Am 28.06.2016 um 09:50 schrieb Yann Ylavic

Re: T 2.4.23 tomorrow (Thurs) ??

+1 (Unless the mod_proxy connection cleanup improvements slip in there, then I'd like to test this more). > Am 28.06.2016 um 13:41 schrieb Jim Jagielski : > > I am thinking of a T today... Anyone see or know of any > reasons for not doing so? Or anyone wish to make uninformed

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

Ah, understood. Do you want to squeeze it into 2.4.23 or can it wait? > Am 28.06.2016 um 13:42 schrieb Yann Ylavic : > > I don't think trunk needs it because ap_proxy_connect_backend() is > already doing this work (via ap_proxy_check_backend). > > That's why I proposed a

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

Dunno, the issue is that reused TLS connections where data are immediately available from the backend may be missing some bytes... On Tue, Jun 28, 2016 at 1:43 PM, Stefan Eissing wrote: > Ah, understood. Do you want to squeeze it into 2.4.23 or can it wait? > >> Am

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

Patch as a file attached. On Tue, Jun 28, 2016 at 1:48 PM, Yann Ylavic wrote: > Maybe if you can test current 2.4.x with this patch and it works as > expected it could be backported... > > On Tue, Jun 28, 2016 at 1:46 PM, Yann Ylavic wrote: >> Dunno,

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

I believe so. Highly experimental and all such... > Am 28.06.2016 um 12:23 schrieb Yann Ylavic : > > I can, but is mod_proxy_h2 CTR (Commit Then Review) like > mod_h2 ? > > On Tue, Jun 28, 2016 at 12:15 PM, Stefan Eissing > wrote: >> Looks

Re: T 2.4.23 tomorrow (Thurs) ??

I am thinking of a T today... Anyone see or know of any reasons for not doing so? Or anyone wish to make uninformed or incorrect assumptions (with veiled threats) against a T for no valid reason other than it's an opportunity to do so? > On Jun 22, 2016, at 4:05 PM, Jim Jagielski

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

Maybe if you can test current 2.4.x with this patch and it works as expected it could be backported... On Tue, Jun 28, 2016 at 1:46 PM, Yann Ylavic wrote: > Dunno, the issue is that reused TLS connections where data are > immediately available from the backend may be

Re: svn commit: r1750392 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/ap_mmn.h modules/proxy/mod_proxy.h modules/proxy/mod_proxy_ajp.c modules/proxy/mod_proxy_fcgi.c modu

On Tue, Jun 28, 2016 at 1:52 PM, Jim Jagielski wrote: > >> On Jun 27, 2016, at 4:25 PM, Yann Ylavic wrote: >> >> On Mon, Jun 27, 2016 at 9:05 PM, Jim Jagielski wrote: >>> On Jun 27, 2016, at 1:26 PM, yla...@apache.org wrote:

Re: svn commit: r1750392 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/ap_mmn.h modules/proxy/mod_proxy.h modules/proxy/mod_proxy_ajp.c modules/proxy/mod_proxy_fcgi.c modu

> On Jun 27, 2016, at 4:25 PM, Yann Ylavic wrote: > > On Mon, Jun 27, 2016 at 9:05 PM, Jim Jagielski wrote: >> >>> On Jun 27, 2016, at 1:26 PM, yla...@apache.org wrote: >>> >>> +apr_bucket_brigade *tmp_bb; >>> } proxy_conn_rec; >>> >> >> I am

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

We are talking about adding this to trunk first, right? ^^ > Am 28.06.2016 um 12:34 schrieb Stefan Eissing : > > I believe so. Highly experimental and all such... > >> Am 28.06.2016 um 12:23 schrieb Yann Ylavic : >> >> I can, but is

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

I don't think trunk needs it because ap_proxy_connect_backend() is already doing this work (via ap_proxy_check_backend). That's why I proposed a 2.4.x only patch, but I can commit it to trunk temporarily if that helps (and until) backport... On Tue, Jun 28, 2016 at 12:36 PM, Stefan Eissing

Re: svn commit: r1750474 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h mod_proxy_ajp.c mod_proxy_fcgi.c mod_proxy_http.c proxy_util.c

On Tue, Jun 28, 2016 at 4:49 PM, Ruediger Pluem wrote: > > > On 06/28/2016 04:26 PM, Ruediger Pluem wrote: >> >> >> On 06/28/2016 01:19 PM, yla...@apache.org wrote: >>> Author: ylavic >>> Date: Tue Jun 28 11:19:36 2016 >>> New Revision: 1750474 >>> >>> URL:

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic wrote: > > I don't see where lbmethod_heartbeat depends on mod_heartmonitor in > the code, but it seems to require mod_slotmem_shm though. My bad, mod_heartmonitor is required too.

Mergine of Multiple Cookie Headers

Hi, We've observed multiple gateways, operated by e.g. AT, COLT and Vodafone, that inject additional Cookie: headers into client requests, such as Cookie: actually=from_the_client Cookie: Bearer-Type=w-TCP Cookie: network-access-type=UMTS Apache httpd merges those headers into a single, comma

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 4:15 PM, William A Rowe Jr wrote: > On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr > wrote: >> >> >> I suppose this would have been the more accurate toggle, in the first >> place? >> Any reason we would build lbmethods

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic wrote: > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic wrote: >> >> I don't see where lbmethod_heartbeat depends on mod_heartmonitor in >> the code, but it seems to require mod_slotmem_shm though. > > My bad,

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic wrote: > On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic wrote: > > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic > wrote: > >> > >> I don't see where lbmethod_heartbeat depends on

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 10:20 AM, Yann Ylavic wrote: > On Tue, Jun 28, 2016 at 5:12 PM, William A Rowe Jr > wrote: > > On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic > wrote: > >> > >> On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr wrote: > > I suppose this would have been the more accurate toggle, in the first > place? > Any reason we would build lbmethods without balancer? > > enable_lbmethod_byrequests=$enable_proxy_balancer >

Re: svn commit: r1750474 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h mod_proxy_ajp.c mod_proxy_fcgi.c mod_proxy_http.c proxy_util.c

On 06/28/2016 01:19 PM, yla...@apache.org wrote: > Author: ylavic > Date: Tue Jun 28 11:19:36 2016 > New Revision: 1750474 > > URL: http://svn.apache.org/viewvc?rev=1750474=rev > Log: > mod_proxy: follow up to r1750392. > Avoid double checking the connection in ap_proxy_connect_backend() when >

Re: svn commit: r1750474 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h mod_proxy_ajp.c mod_proxy_fcgi.c mod_proxy_http.c proxy_util.c

On 06/28/2016 04:26 PM, Ruediger Pluem wrote: > > > On 06/28/2016 01:19 PM, yla...@apache.org wrote: >> Author: ylavic >> Date: Tue Jun 28 11:19:36 2016 >> New Revision: 1750474 >> >> URL: http://svn.apache.org/viewvc?rev=1750474=rev >> Log: >> mod_proxy: follow up to r1750392. >> Avoid double

Re: T 2.4.23 tomorrow (Thurs) ??

On 06/28/2016 04:15 PM, William A Rowe Jr wrote: > On Tue, Jun 28, 2016 at 8:46 AM, William A Rowe Jr > wrote: > > > I suppose this would have been the more accurate toggle, in the first > place? > Any reason we would build lbmethods

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski wrote: > I am thinking of a T today... Anyone see or know of any > reasons for not doing so? > Of the changes we just backported, there is one side effect, Jens wasn't imagining things. From this query... grep -E "^[

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 5:12 PM, William A Rowe Jr wrote: > On Tue, Jun 28, 2016 at 10:10 AM, Yann Ylavic wrote: >> >> On Tue, Jun 28, 2016 at 5:06 PM, Yann Ylavic wrote: >> > On Tue, Jun 28, 2016 at 5:04 PM, Yann Ylavic

Re: svn commit: r1750507 - /httpd/httpd/trunk/modules/proxy/balancers/config2.m4

This patch alone was insufficient, in a stock ./configure with the default settings of 'most', 'shared', we don't have lbmodules (thanks to Jens again for calling this out). Ranier, can you shed light on one line from your commit https://svn.apache.org/viewvc?view=revision=952007 I think this

Re: Mergine of Multiple Cookie Headers

On 28 Jun 2016, at 4:29 PM, Rainer Canavan wrote: > We've observed multiple gateways, operated by e.g. AT, COLT and > Vodafone, that inject additional Cookie: headers into client requests, > such as > > Cookie: actually=from_the_client > Cookie: Bearer-Type=w-TCP >

Re: T 2.4.23 tomorrow (Thurs) ??

On Tue, Jun 28, 2016 at 6:41 AM, Jim Jagielski wrote: > I am thinking of a T today... Anyone see or know of any > reasons for not doing so? As far as Jens and I have been able to determine, there are no remaining edge cases once the critical patch in STATUS is applied to undo

Re: Merging of Multiple Cookie Headers

On Tue, Jun 28, 2016 at 6:09 PM, Graham Leggett wrote: > On 28 Jun 2016, at 4:29 PM, Rainer Canavan > wrote: > >> We've observed multiple gateways, operated by e.g. AT, COLT and >> Vodafone, that inject additional Cookie: headers into client

Re: Merging of Multiple Cookie Headers

On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan wrote: > > It's not just the Cookie that's logged via %{}C that gets nonsense > appended, but the cookie parser of e.g. PHP behaves the same. I think > httpd could handle this better by not merging the headers or

Re: svn commit: r1750571 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/programs/configure.xml

Credit where credit is due, Jens caught this docs error in the process of testing the ./configure scenarios... On Tue, Jun 28, 2016 at 2:56 PM, wrote: > --- httpd/httpd/branches/2.4.x/docs/manual/programs/configure.xml > (original) > +++

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

Thanks. I had to change from r-> to ctx->rbase, but otherwise works fine. Shall I commit this and potentially break Jim's tagging again? -Stefan httpd-2.4.x-mod_proxy_http2-ssl_reuse_cleanup-v2.diff Description: Binary data > Am 28.06.2016 um 13:49 schrieb Yann Ylavic :

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

Commited in r1750505. > Am 28.06.2016 um 15:13 schrieb Yann Ylavic : > > Jim didn't tag yet AFAICT, did he? > If not, since it's mod_proxy_http2 scope only, +1 for me. > > On Tue, Jun 28, 2016 at 3:02 PM, Stefan Eissing > wrote: >> Thanks. I

Re: Merging of Multiple Cookie Headers

Or use ssl so proxies can't monkey with the request headers. Sent from my iPhone > On Jun 28, 2016, at 7:48 PM, Joseph Schaefer wrote: > > Sales pitch: use libapreq2, which gracefully handles merged cookie headers > anyway. > > Sent from my iPhone > >> On Jun 28,

Re: Merging of Multiple Cookie Headers

Sales pitch: use libapreq2, which gracefully handles merged cookie headers anyway. Sent from my iPhone > On Jun 28, 2016, at 6:39 PM, Joseph Schaefer wrote: > > The industry standard behavior regarding cookies is for user agents to send > at most a single cookie

Re: Merging of Multiple Cookie Headers

Anyways I agree with Bill that this isn't httpd's problem to fix. The cookie standards are abysmal which is why some level of strictness is required as regards the defacto httpd behavior to prevent all hell from breaking loose. Sent from my iPhone > On Jun 28, 2016, at 7:51 PM, Joseph

Re: Merging of Multiple Cookie Headers

On Tue, Jun 28, 2016 at 10:13 PM, William A Rowe Jr wrote: > On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan > wrote: >> It's not just the Cookie that's logged via %{}C that gets nonsense >> appended, but the cookie parser of e.g. PHP behaves the

Re: Merging of Multiple Cookie Headers

The industry standard behavior regarding cookies is for user agents to send at most a single cookie header, and for servers to avoid merging set-cookie headers. The set-cookie2 header is merge able. Sent from my iPhone > On Jun 28, 2016, at 6:14 PM, Rainer Canavan

Re: Merging of Multiple Cookie Headers

Php's cookie parser can be more lax in treating ", " similar to "; ", that would be a better avenue of redress. Otherwise they can adopt libapreq2's cookie parsing code which has much richer support for merging cookie headers written to different cookie specs. Sent from my iPhone > On Jun

Re: svn commit: r1750301 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h proxy_util.c

Jim didn't tag yet AFAICT, did he? If not, since it's mod_proxy_http2 scope only, +1 for me. On Tue, Jun 28, 2016 at 3:02 PM, Stefan Eissing wrote: > Thanks. I had to change from r-> to ctx->rbase, but otherwise works fine. > > Shall I commit this and potentially