Re: mod_speling changes in trunk and backport

[Christophe JAILLET]

Le 23/02/2016 20:24, Rainer Jung a écrit :
There were two changes to mod_speling in trunk in 2013/2014. They were 
motivated by PR 44221: although the docs claim that using 
"CheckCaseOnly On" "limits the action of the spelling correction to 
lower/upper case changes. Other potential corrections are not 
performed." In fact mod_speling still checks for content files which 
only differ in the file name suffix form the request URI. That part of 
the code was contained in an #ifdef but active by default. The changes 
introduce a new directive that allows to control that part of the 
behavior by configuration.


Now the question: it seems to me that due to the change being done in 
two steps, now the directive CheckCaseOnly and the new one 
CheckBasenameMatch are not independent of each other. Setting 
CheckBasenameMatch  to "On" only enables the suffix handling if 
CheckCaseOnly if "Off". For improved compatibility and for better 
orthogonality I would suggest to keep the features separate from each 
other, ie.:


Index: modules/mappers/mod_speling.c
===
--- modules/mappers/mod_speling.c   (revision 1731929)
+++ modules/mappers/mod_speling.c   (working copy)
@@ -326,8 +326,7 @@
  * because it won't find anything matching that spelling.
  * With the extension-munging, it would locate "foobar.html".
  */
-else if ((cfg->check_case_only == 0) &&
- (cfg->check_basename_match == 1)) {
+else if (cfg->check_basename_match == 1) {
 /*
  * Okay... we didn't find anything. Now we take out the 
hard-core
  * power tools. There are several cases here. Someone 
might have



That way the old changes could be ported back to 2.4 with the only 
change that the default for CheckBasenameMatch would be "On" in 2.4 
for compatibility reasons and "Off" in trunk to satisfy the principle 
of least surprise.


Regards,

Rainer


Hi,

One other remark from Eric at the time being [1] was that is also 
changed the legacy behavior.
Having CheckBasenameMatch default to 1 (at least for 2.4.x) would keep 
compatibility with existing config.


Keeping the 2 options independent would also require a tweak in the doc.

CJ

[1] 
http://mail-archives.apache.org/mod_mbox/httpd-cvs/201401.mbox/%3c20140128052621.21f912388...@eris.apache.org%3E

Re: conn_rec needs a context

[Yann Ylavic]

On Wed, Mar 2, 2016 at 1:23 AM, Yann Ylavic  wrote:
> Hi,
>
> On Wed, Mar 2, 2016 at 1:09 AM, Graham Leggett  wrote:
>>
>> Would it make sense to add a vector of contexts that same way we have a 
>> vector of configs, one slot for each module, which will allow any module to 
>> add a context of it’s own to conn_rec without having to extend conn_rec?
>
> Can't the existing ap_[gs]et_module_config(c->conn_config, ...) be
> used for that purpose?

I mean, put the context in the module config?

Re: conn_rec needs a context

[Yann Ylavic]

Hi,

On Wed, Mar 2, 2016 at 1:09 AM, Graham Leggett  wrote:
>
> Would it make sense to add a vector of contexts that same way we have a 
> vector of configs, one slot for each module, which will allow any module to 
> add a context of it’s own to conn_rec without having to extend conn_rec?

Can't the existing ap_[gs]et_module_config(c->conn_config, ...) be
used for that purpose?

>
> It would be nice to have the same for requests, for the same reason.

Likewise with r->request_config?

Regards,
Yann.

conn_rec needs a context

[Graham Leggett]

Hi all,

In order to get connections to have async behaviour, it must be possible for 
the process_connection hook to exit in the expectation of being called again 
when an async mpm is present - this is easy, the mpms already do that.

The missing bit is that conn_rec needs a context so that when is is called a 
second time it knows what state it is in.

There is a void *ctx variable that was added in r1565657, but I’m not sure it 
is enough.

Would it make sense to add a vector of contexts that same way we have a vector 
of configs, one slot for each module, which will allow any module to add a 
context of it’s own to conn_rec without having to extend conn_rec?

It would be nice to have the same for requests, for the same reason.

Thoughts?

Regards,
Graham
—

Re: svn commit: r1727603 - in /httpd/httpd/trunk: CHANGES server/mpm/event/event.c

[Yann Ylavic]

On Wed, Mar 2, 2016 at 12:59 AM, Yann Ylavic  wrote:
> On Fri, Jan 29, 2016 at 4:51 PM,   wrote:
>>
>> +static void setup_slave_conn(conn_rec *c, void *csd)
>> +{
>> +event_conn_state_t *mcs;
>> +event_conn_state_t *cs;
>> +
>> +mcs = ap_get_module_config(c->master->conn_config, &mpm_event_module);
>> +
>> +cs = apr_pcalloc(c->pool, sizeof(*cs));
>> +cs->c = c;
>> +cs->r = NULL;
>> +cs->sc = mcs->sc;
>> +cs->suspended = 0;
>> +cs->p = c->pool;
>> +cs->bucket_alloc = c->bucket_alloc;
>
> Can the slave connection really have the same bucket_alloc as the master?
> Can't both be processed (i.e. process_socket) at the same time?

Forget that, I have read it as: cs->bucket_alloc = mcs->bucket_alloc :p

Re: svn commit: r1727603 - in /httpd/httpd/trunk: CHANGES server/mpm/event/event.c

[Yann Ylavic]

On Fri, Jan 29, 2016 at 4:51 PM,   wrote:
> Author: icing
> Date: Fri Jan 29 15:51:25 2016
> New Revision: 1727603
>
> URL: http://svn.apache.org/viewvc?rev=1727603&view=rev
> Log:
> event: slave connection init, vhost early config
>
> Modified:
> httpd/httpd/trunk/server/mpm/event/event.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=1727603&r1=1727602&r2=1727603&view=diff
> ==
> --- httpd/httpd/trunk/server/mpm/event/event.c (original)
> +++ httpd/httpd/trunk/server/mpm/event/event.c Fri Jan 29 15:51:25 2016
> @@ -3293,6 +3293,55 @@ static int event_run(apr_pool_t * _pconf
>  return OK;
>  }
>
> +static void setup_slave_conn(conn_rec *c, void *csd)
> +{
> +event_conn_state_t *mcs;
> +event_conn_state_t *cs;
> +
> +mcs = ap_get_module_config(c->master->conn_config, &mpm_event_module);
> +
> +cs = apr_pcalloc(c->pool, sizeof(*cs));
> +cs->c = c;
> +cs->r = NULL;
> +cs->sc = mcs->sc;
> +cs->suspended = 0;
> +cs->p = c->pool;
> +cs->bucket_alloc = c->bucket_alloc;

Can the slave connection really have the same bucket_alloc as the master?
Can't both be processed (i.e. process_socket) at the same time?

> +cs->pfd = mcs->pfd;
> +cs->pub = mcs->pub;

Looks unnecessary, since the two pub's (only) fields below are overwritten.

> +cs->pub.state = CONN_STATE_READ_REQUEST_LINE;
> +cs->pub.sense = CONN_SENSE_DEFAULT;
> +
> +c->cs = &(cs->pub);
> +ap_set_module_config(c->conn_config, &mpm_event_module, cs);
> +}

Regards,
Yann.

Re: state of h2 (long)

[Stefan Eissing]

Yeah! I'll get that in tomorrow. Nice work!

> Am 01.03.2016 um 22:13 schrieb Jacob Champion :
> 
>> On Tue, Mar 1, 2016 at 11:08 AM, Jacob Champion  wrote:
>> I still don't have my OpenSSL build process for Windows down enough to
>> test out an h2 proxy, but that'll be my next trick.
> 
> Looks like an HTTP/1.1 -> h2 proxy works for me as well on Windows,
> once I got a functioning SSLProxyEngine. This is cool stuff!
> 
> --Jacob

Re: Backport of auto proxy(_util) exports?

[NormW]

G/M,
As of last night the following additional exports from 2.4 mod_proxy 
builds all NetWare modules presently in the 2.4 modules/proxy dir:

Index: modules/proxy/NWGNUproxy
===
--- modules/proxy/NWGNUproxy(revision 1733007)
+++ modules/proxy/NWGNUproxy(working copy)
@@ -273,6 +273,7 @@
@echo $(DL) proxy_run_scheme_handler,$(DL)>> $@
@echo $(DL) ap_proxy_acquire_connection,$(DL)>> $@
@echo $(DL) ap_proxy_backend_broke,$(DL)>> $@
+   @echo $(DL) ap_proxy_buckets_lifetime_transform,$(DL)>> $@
@echo $(DL) ap_proxy_c2hex,$(DL)>> $@
@echo $(DL) ap_proxy_canon_netloc,$(DL)>> $@
@echo $(DL) ap_proxy_canonenc,$(DL)>> $@
@@ -318,6 +319,7 @@
@echo $(DL) ap_proxy_strncpy,$(DL)>> $@
@echo $(DL) ap_proxy_sync_balancer,$(DL)>> $@
@echo $(DL) ap_proxy_trans_match,$(DL)>> $@
+   @echo $(DL) ap_proxy_transfer_between_connections,$(DL)>> $@
@echo $(DL) ap_proxy_valid_balancer_name,$(DL)>> $@
@echo $(DL) ap_proxy_worker_name,$(DL)>> $@
@echo $(DL) ap_proxyerror$(DL)>> $@

Norm

On 1/03/2016 2:09 PM, Rainer Jung wrote:

Am 29.02.2016 um 23:03 schrieb NormW:

G/M Rainer,
Any known reason your recent tweaks to automatically create the
mod_proxy exports list cannot be nominated for back-port to 2.4.x?


Not that I'm aware off. Things have settled a bit now, so probably it'
the time to propose a backport.


If there is a technical and/or time constraint I'll submit a patch for
at least a couple of symbols needed to build 2.4.x/modules/proxy.


That would be great!

Rainer


Index: modules/proxy/NWGNUproxy
===
--- modules/proxy/NWGNUproxy	(revision 1733007)
+++ modules/proxy/NWGNUproxy	(working copy)
@@ -273,6 +273,7 @@
 	@echo $(DL) proxy_run_scheme_handler,$(DL)>> $@
 	@echo $(DL) ap_proxy_acquire_connection,$(DL)>> $@
 	@echo $(DL) ap_proxy_backend_broke,$(DL)>> $@
+	@echo $(DL) ap_proxy_buckets_lifetime_transform,$(DL)>> $@
 	@echo $(DL) ap_proxy_c2hex,$(DL)>> $@
 	@echo $(DL) ap_proxy_canon_netloc,$(DL)>> $@
 	@echo $(DL) ap_proxy_canonenc,$(DL)>> $@
@@ -318,6 +319,7 @@
 	@echo $(DL) ap_proxy_strncpy,$(DL)>> $@
 	@echo $(DL) ap_proxy_sync_balancer,$(DL)>> $@
 	@echo $(DL) ap_proxy_trans_match,$(DL)>> $@
+	@echo $(DL) ap_proxy_transfer_between_connections,$(DL)>> $@
 	@echo $(DL) ap_proxy_valid_balancer_name,$(DL)>> $@
 	@echo $(DL) ap_proxy_worker_name,$(DL)>> $@
 	@echo $(DL) ap_proxyerror$(DL)>> $@

Re: state of h2 (long)

[Jacob Champion]

On Tue, Mar 1, 2016 at 11:08 AM, Jacob Champion  wrote:
> I still don't have my OpenSSL build process for Windows down enough to
> test out an h2 proxy, but that'll be my next trick.

Looks like an HTTP/1.1 -> h2 proxy works for me as well on Windows,
once I got a functioning SSLProxyEngine. This is cool stuff!

--Jacob

Re: state of h2 (long)

[Jacob Champion]

On Mon, Feb 29, 2016 at 1:55 PM, Jacob Champion  wrote:
> I'm only just figuring out how to actually test the proxy module at
> runtime, though, so... caveat emptor.

FWIW, with that patchset, I was able to get an h2c (plaintext) proxy
working with the nghttp2.org test server. So that's a good sign. I
still don't have my OpenSSL build process for Windows down enough to
test out an h2 proxy, but that'll be my next trick.

That said, the h2c proxy needed an additional patch to work --
mod_proxy_http2's URL canonicalization removes port 80 from h2c://
URLs, but mod_proxy doesn't know which port to use for the h2c
pseudo-scheme, so the proxy fails. One possible solution (patch
attached) is to add the h2c and h2 schemes to the proxy_schemes_t list
in proxy_util.c. I don't know if that's the *right* solution, but it
works for me?

--Jacob


http2-proxy-ports.patch
Description: Binary data

RE: access control for dynamic hosts

[fabien]

Hello Rick,

Forward doesn’t mean dynamic, however, and using one particular solution 
like that is misleading, IMO.  Using “forward-dns” makes more sense to 
me.


Yep, with such a name what it does is pretty clear.

That said, how would you intend to handle multiple A records for the 
same name: look them all up and store in a table, or support only one A 
record per name?  At a minimum, I think that needs to be clearly 
documented.


Sure. The "poc" implementation posted up-thread walks over all the records 
till a match is found, or this is a deny.


There is no attempt at caching anything, as the actual use case is to deal 
with dynamic dns hosts, so with pretty short refresh times. Caching is the 
problem of the dns resolver.


--
Fabien.

Re: state of h2 (long)

[Jim Jagielski]

> On Mar 1, 2016, at 9:46 AM, Graham Leggett  wrote:
> 
> On 29 Feb 2016, at 10:33 PM, Jim Jagielski  wrote:
> 
>> I've been digging into how we could better leverage serf on the mod_proxy
>> side w/o going the route of mod_serf itself...  Agreed that using
>> pollsets et.al. would be useful. Maybe some of the motorz mpm logic
>> could be used by mod_proxy…?
> 
> I currently think everything we need is now there.
> 
> I am in the process of adding TCP protocol support to the core and to the 
> proxy (in other words we can be a TCP proxy in addition to an HTTP proxy), 
> and am trying to see what problems we run into that stop us doing this 
> asynchronously.

WOW! That is super cool!

Really looking forward to it!

> 
> (What I want to achieve is an SNI proxy, in other words a TCP proxy that 
> interprets enough of an SSL handshake to extract the SNI header, and use that 
> name as the basis of a TCP tunnel to some backend server which then completes 
> that SSL handshake. My end goal is that I can TLS client certificate all the 
> way to a backend server without terminating that TLS connection on the proxy, 
> and not use a dedicated IP per endpoint.)
> 
> Regards,
> Graham
> —
> 

RE: access control for dynamic hosts

[Houser, Rick]

Forward doesn’t mean dynamic, however, and using one particular solution like 
that is misleading, IMO.  Using “forward-dns” makes more sense to me.

That said, how would you intend to handle multiple A records for the same name: 
look them all up and store in a table, or support only one A record per name?  
At a minimum, I think that needs to be clearly documented.


Rick Houser

From: Yehuda Katz [mailto:yeh...@ymkatz.net]
Sent: Tuesday, March 01, 2016 10:09 AM
To: dev@httpd.apache.org
Subject: Re: access control for dynamic hosts

dyndns is a company name, but it seems to be synonymous for a lot of systems 
with dynamic-dns.
That would make a recognizable option for a lot of people.

- Y

On Tue, Mar 1, 2016 at 10:00 AM, Eric Covener 
mailto:cove...@gmail.com>> wrote:
On Tue, Mar 1, 2016 at 9:53 AM,  mailto:fab...@apache.org>> 
wrote:
> Maybe "Require ip" could be extended instead of using a new name:
>
>   "Require ip myserver.apache.org"


Unfortunately I think you need to pick an awkward name here so it
cannot be confused/misused.  Like "forward-dns"

--
Eric Covener
cove...@gmail.com

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

[Yann Ylavic]

On Tue, Mar 1, 2016 at 4:29 PM, Eric Covener  wrote:
>
> intentional?

No :/
Reverted in r1733055 and re-commited in r1733056 already.

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

[Eric Covener]

On Tue, Mar 1, 2016 at 7:31 AM,   wrote:
> Author: ylavic
> Date: Tue Mar  1 12:31:40 2016
> New Revision: 1733054
>
> URL: http://svn.apache.org/viewvc?rev=1733054&view=rev
> Log:
> mod_proxy: follow up to r1729826 + r1729847 + r1732986.
> Don't use magic constants.
>
> Modified:
> httpd/httpd/trunk/modules/filters/mod_reqtimeout.c
> httpd/httpd/trunk/modules/proxy/mod_proxy.h
> httpd/httpd/trunk/modules/proxy/proxy_util.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=1733054&r1=1733053&r2=1733054&view=diff
> ==
> --- httpd/httpd/trunk/modules/filters/mod_reqtimeout.c (original)
> +++ httpd/httpd/trunk/modules/filters/mod_reqtimeout.c Tue Mar  1 12:31:40 
> 2016
> @@ -352,6 +352,15 @@ out:
>  return rv;
>  }
>
> +static apr_status_t reqtimeout_pause(ap_filter_t *f, apr_bucket_brigade *bb)
> +{
> +if (!APR_BRIGADE_EMPTY(bb) && AP_BUCKET_IS_EOR(APR_BRIGADE_LAST(bb))) {
> +reqtimeout_con_cfg *ccfg = f->ctx;
> +ccfg->timeout_at = 0;
> +}
> +return ap_pass_brigade(f->next, bb);
> +}
> +
>  static int reqtimeout_init(conn_rec *c)


intentional?

-- 
Eric Covener
cove...@gmail.com

Re: access control for dynamic hosts

[Yehuda Katz]

dyndns is a company name, but it seems to be synonymous for a lot of
systems with dynamic-dns.
That would make a recognizable option for a lot of people.

- Y

On Tue, Mar 1, 2016 at 10:00 AM, Eric Covener  wrote:

> On Tue, Mar 1, 2016 at 9:53 AM,   wrote:
> > Maybe "Require ip" could be extended instead of using a new name:
> >
> >   "Require ip myserver.apache.org"
>
>
> Unfortunately I think you need to pick an awkward name here so it
> cannot be confused/misused.  Like "forward-dns"
>
> --
> Eric Covener
> cove...@gmail.com
>

Re: access control for dynamic hosts

[Yann Ylavic]

On Tue, Mar 1, 2016 at 3:31 PM, Eric Covener  wrote:
> On Tue, Mar 1, 2016 at 8:19 AM, Yann Ylavic  wrote:
>> How about "Require dns" (and mod_authz_dns) for the name?
>
> I think it is  reasonable to extend authz_host to disable the reverse
> check when requested (via some new first arg to require)

Good idea.

Re: access control for dynamic hosts

[Yann Ylavic]

On Tue, Mar 1, 2016 at 4:01 PM, Yann Ylavic  wrote:
> On Tue, Mar 1, 2016 at 3:31 PM, Eric Covener  wrote:
>> On Tue, Mar 1, 2016 at 8:19 AM, Yann Ylavic  wrote:
>>> How about "Require dns" (and mod_authz_dns) for the name?
>>
>> I think it is  reasonable to extend authz_host to disable the reverse
>> check when requested (via some new first arg to require)
>
> Good idea.

Oups, it seems this has been abandoned already :p

Re: access control for dynamic hosts

[fabien]

Hello Yann,


[...]

Looks good to me.

It would have to be documented though, especially the difference with
"Require host" and maybe their complementarity (wrt security).


Sure, it needs a documentation, obviously. I will not commit anything 
without a doc.



How about "Require dns" (and mod_authz_dns) for the name?


Hmm. Note that "Require host" also uses the DNS, doubly so. I'm not sure 
that naming one "dns" might not suggest that the other ones would not use 
it?


I think that "Require host" should really be name "Require domain" because 
it is what it does, then "Require host" would be available... but this is 
too late:-)


Maybe "Require ip" could be extended instead of using a new name:

  "Require ip myserver.apache.org"

Would query the DNS to get the IP when checking for the authorization.
Not sure that it is a good idea, though.

--
Fabien.

Re: access control for dynamic hosts

[Eric Covener]

On Tue, Mar 1, 2016 at 9:53 AM,   wrote:
> Maybe "Require ip" could be extended instead of using a new name:
>
>   "Require ip myserver.apache.org"


Unfortunately I think you need to pick an awkward name here so it
cannot be confused/misused.  Like "forward-dns"

-- 
Eric Covener
cove...@gmail.com

Re: access control for dynamic hosts

[fabien]

How about "Require dns" (and mod_authz_dns) for the name?


I think it is  reasonable to extend authz_host to disable the reverse
check when requested (via some new first arg to require)


Note that the inner working logic is different, but this is an 
implementation detail.


What syntax would be appropriate?

  Require forward host foo.apache.org
  Require host forward-only foo.apache.org

Or maybe just a tag in front of the names?

  Require host mydomain.org !mydynahost.domain.org
  Require host mydomain.org *mydynahost.domain.org
  Require host mydomain.org ?mydynahost.domain.org

???

--
Fabien.

Re: state of h2 (long)

[Graham Leggett]

On 29 Feb 2016, at 10:33 PM, Jim Jagielski  wrote:

> I've been digging into how we could better leverage serf on the mod_proxy
> side w/o going the route of mod_serf itself...  Agreed that using
> pollsets et.al. would be useful. Maybe some of the motorz mpm logic
> could be used by mod_proxy…?

I currently think everything we need is now there.

I am in the process of adding TCP protocol support to the core and to the proxy 
(in other words we can be a TCP proxy in addition to an HTTP proxy), and am 
trying to see what problems we run into that stop us doing this asynchronously.

(What I want to achieve is an SNI proxy, in other words a TCP proxy that 
interprets enough of an SSL handshake to extract the SNI header, and use that 
name as the basis of a TCP tunnel to some backend server which then completes 
that SSL handshake. My end goal is that I can TLS client certificate all the 
way to a backend server without terminating that TLS connection on the proxy, 
and not use a dedicated IP per endpoint.)

Regards,
Graham
—

Re: access control for dynamic hosts

[Eric Covener]

On Tue, Mar 1, 2016 at 8:19 AM, Yann Ylavic  wrote:
> How about "Require dns" (and mod_authz_dns) for the name?

I think it is  reasonable to extend authz_host to disable the reverse
check when requested (via some new first arg to require)

Re: access control for dynamic hosts

[Jacob Perkins]

This would be a god send. I personally use a lot of dynamic hosts from my ISP, 
in that I’m unable to control the rDNS records of the IPs I’m assigned. Having 
an option for checks going ‘forward’ only would be terrific.

—
Jacob Perkins
Product Owner
cPanel Inc.

jacob.perk...@cpanel.net 
Office:  713-529-0800 x 4046
Cell:  713-560-8655

> On Mar 1, 2016, at 6:44 AM, fab...@apache.org wrote:
> 
>  Require xxx foo.apache.org 
>  # allows ip of "foo.apache.org ", just be resolving 
> the name
> 
> For use with dyndns services.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: access control for dynamic hosts

[Yann Ylavic]

Hi Fabien,

On Thu, Jan 14, 2016 at 9:38 AM, Fabien  wrote:
>
> Would anyone have an opinion, please?
>
> Although I can just commit the proposed changes, a formal go would be nice.

Looks good to me.

It would have to be documented though, especially the difference with
"Require host" and maybe their complementarity (wrt security).

How about "Require dns" (and mod_authz_dns) for the name?

Regards,
Yann.

Re: access control for dynamic hosts

[fabien]

This feature makes sense because it allows to allow a full domain, say
"apache.org", any host of which the inverse dns resolves to the domain
can then be allowed.

But this also means that if the reverse dns is not controlled, say with
the dynamic dns and a moving ip, ip control does not work, hence my
proposal for a lesser version which just checks that a client ip is
allowed just by resolving a name.


that is unsafe


it takes me exactly 5 seconds to add a PTR "myserver.apache.org" to one of 
our public ip-addresses if i would like to and nobody can do anything against 
it except check if the A record matchs because that can only be controlled by 
the domain owner


Indeed, but then "host" also checks that forward resolution works, that is 
"myserver.apache.org" must *also* point back to the same IP.


the same for anybody else who has a /24 or bigger network and the reverse dns 
delegated to his own namservers - i would not do such things, others would 
and so it's nothing to hand authentication on it


Sure, the second forward checks that all is well.


The feature I'm proposing is not related to that. I'm suggesting to have a 
way to specify host names *only* which are checked forward *only*.


  Require xxx foo.apache.org
  # allows ip of "foo.apache.org", just be resolving the name

For use with dyndns services.

--
Fabien.

Re: svn commit: r1732986 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Yann Ylavic]

On Tue, Mar 1, 2016 at 1:26 PM, Plüm, Rüdiger, Vodafone Group
 wrote:
>
>> From: Jim Jagielski [mailto:j...@jagunet.com]
>>
>> I'd prefer we use a define, eg:
>>
>> #define PROXY_WORKER_RFC1035_SIZE 512
>>
>> rather than embedding magic numbers...
>
> +1

Agreed, much better, committed in r1733056.

Thanks for the review,
Yann.

RE: svn commit: r1732986 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Plüm , Rüdiger , Vodafone Group]

> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Dienstag, 1. März 2016 12:58
> To: dev@httpd.apache.org
> Cc: c...@httpd.apache.org
> Subject: Re: svn commit: r1732986 -
> /httpd/httpd/trunk/modules/proxy/proxy_util.c
> 
> I'd prefer we use a define, eg:
> 
> #define PROXY_WORKER_RFC1035_SIZE 512
> 
> rather than embedding magic numbers...

+1

Regards

Rüdiger

> 
> > On Feb 29, 2016, at 8:20 PM, yla...@apache.org wrote:
> >
> > Author: ylavic
> > Date: Tue Mar  1 01:20:06 2016
> > New Revision: 1732986
> >
> > URL: http://svn.apache.org/viewvc?rev=1732986&view=rev
> > Log:
> > mod_proxy: follow up to r1729826 + r1729847.
> > Adjust stacked ssl_hostname maximum size.
> >
> > Modified:
> >httpd/httpd/trunk/modules/proxy/proxy_util.c
> >
> > Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?
> rev=1732986&r1=1732985&r2=1732986&view=diff
> >
> ==
> 
> > --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
> > +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Tue Mar  1 01:20:06
> 2016
> > @@ -2721,7 +2721,7 @@ PROXY_DECLARE(int) ap_proxy_connect_back
> >  * restore any ssl_hostname for this connection set earlier
> by
> >  * ap_proxy_determine_connection().
> >  */
> > -char ssl_hostname[PROXY_WORKER_MAX_HOSTNAME_SIZE];
> > +char ssl_hostname[512]; /* host+domain names max (rfc1035-
> 2.3.4) */
> > if (!conn->ssl_hostname || PROXY_STRNCPY(ssl_hostname,
> >  conn-
> >ssl_hostname)) {
> > ssl_hostname[0] = '\0';
> >
> >

Re: svn commit: r1732986 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Jim Jagielski]

I'd prefer we use a define, eg:

#define PROXY_WORKER_RFC1035_SIZE 512

rather than embedding magic numbers...

> On Feb 29, 2016, at 8:20 PM, yla...@apache.org wrote:
> 
> Author: ylavic
> Date: Tue Mar  1 01:20:06 2016
> New Revision: 1732986
> 
> URL: http://svn.apache.org/viewvc?rev=1732986&view=rev
> Log:
> mod_proxy: follow up to r1729826 + r1729847.
> Adjust stacked ssl_hostname maximum size.
> 
> Modified:
>httpd/httpd/trunk/modules/proxy/proxy_util.c
> 
> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1732986&r1=1732985&r2=1732986&view=diff
> ==
> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Tue Mar  1 01:20:06 2016
> @@ -2721,7 +2721,7 @@ PROXY_DECLARE(int) ap_proxy_connect_back
>  * restore any ssl_hostname for this connection set earlier by
>  * ap_proxy_determine_connection().
>  */
> -char ssl_hostname[PROXY_WORKER_MAX_HOSTNAME_SIZE];
> +char ssl_hostname[512]; /* host+domain names max (rfc1035-2.3.4) 
> */
> if (!conn->ssl_hostname || PROXY_STRNCPY(ssl_hostname,
>  conn->ssl_hostname)) {
> ssl_hostname[0] = '\0';
> 
> 

Re: state of h2 (long)

[Stefan Eissing]

I am very glad that someone is looking into this... if I can be of any help, 
let me know.

> Am 29.02.2016 um 22:55 schrieb Jacob Champion :
> 
> On Mon, Feb 29, 2016 at 9:35 AM, William A Rowe Jr  
> wrote:
>> On Sun, Feb 28, 2016 at 1:37 PM, Gregg Smith  wrote:
>>> 
>>> Hi Stefan,
>>> 
>>> I've had a real lack of time lately to do much on trunk's mod_http2 on the
>>> windows side. The new mod_proxy_http2 requires a few functions from
>>> mod_http2 and with what time I have had I have been unsuccessful figuring
>>> out how to get these functions exported. So if you (or anyone else) can
>>> figure this out, I'd appreciate it
>> 
>> Looking at this today.
> 
> Oops, I probably started duplicating some of your work then. In case
> it is still useful... my current work in progress is a set of three
> patches, up at
> 
>   https://github.com/jchampio/httpd/commits/dev/cmake-http2
> 
> The first two patches are general CMake changes:
> - use CMake generator expressions so that multi-configuration
> generators (e.g. Visual Studio 2015) can correctly install build
> artifacts like PDBs
> - a change to path quoting so that we can install to paths with quotes
> in them (e.g. "Program Files")
> 
> The third patch is the one that gets mod_proxy_http2 compiling (export
> the three h2_iq symbols, fix up the APLOG usage, etc).
> 
> I'm only just figuring out how to actually test the proxy module at
> runtime, though, so... caveat emptor.
> 
>> Between Jeff's first effort @ 
>> https://github.com/trawick/nghttp2-minimal-cmake
>> and a broader effort w/
>> https://github.com/tatsuhiro-t/nghttp2/issues/448#issuecomment-182849066
>> the cmake builds for nghttp2 look almost simple, which is what I'm looking
>> at for the moment.
> 
> Ooh, nice! My MinGW build of nghttp2 this morning was a little
> painful... looking forward to having this.
> 
> --Jacob