date:20160211

Re: httpd-trunk/modules/http2 gets a proxy

2016-02-11 Thread Stefan Eissing

Uhm, is there an unresolved conflict in the first file?

-Stefan

PS. You know, it *would* actually be easier if you had commit access... ;-)

> Am 11.02.2016 um 03:09 schrieb NormW :
> 
> G/A Stefan,
> My BBAADD. Until recently /http2 was home only to mod_http2, and to keep 
> things automatic my NWGNUmakefile in there used a wildcard *.c to get the 
> list of object files to build there. When the compile  failed due to added .c 
> files I made a few tweaks to the NWGNU and it all linked without issue again 
> so I forwarded the small tweaks. Closer reading of the list and the added .c 
> revealed there are (at least) two modules now in /http2. This necessitated a 
> change of the NWGNU to use a specified list of .c for a start, and removal of 
> a couple of the patch lines I'd recently sent. Because other modules will be 
> sharing the same dir I've renamed the original NWNUmakefile to NWGNUmod_http2 
> and there is now a new NWGNUmakefile whose only job is to call the other 
> NWGNU files that will eventually exist in the dir. (If all this sounds 
> confusing it probably is, but by way of example see /proxy dir and note a 
> NWGNUmakefile that contains a list of executables to build.)
> 
> If we are still speaking after explaining all that, the new files are 
> attached, thus:
> : NWGUmod_http2 which now has the list of /http2 files to build mod_http2;
> 
> : NWGNUmakefile which, FTM, has a list of modules to build, but I won't try 
> to explain why the list has a double entry if there is only one (so far) to 
> build.
> 
> Hopefully I will eventually work out a process to do away with this 
> 'additional' NWGNUmakefile, which would allow removal of quite a few from the 
> source tree.
> Apologies for the bother,
> Norm
> 
> On 10/02/2016 10:34 PM, Stefan Eissing wrote:
>> Applied in r1729583. Thanks!
>> 
>>> Am 08.02.2016 um 23:07 schrieb NormW :
> 
> 
>>> G/M,
>>> Recent additions to http-trunk/modules/http2 require the attached apatch to 
>>> the http2 NetWare build file:
 Index: modules/http2/NWGNUmakefile
 ===
 --- modules/http2/NWGNUmakefile(revision 1729251)
 +++ modules/http2/NWGNUmakefile(working copy)
 @@ -34,6 +34,8 @@
$(NGH2SRC)/lib/ \
$(NGH2SRC)/lib/includes \
$(SERVER)/mpm/NetWare \
 +  $(STDMOD)/proxy \
 +  $(STDMOD)/ssl \
$(NWOS) \
$(EOLIST)
 
 @@ -55,6 +57,7 @@
 #
 XLFLAGS+= \
-L$(OBJDIR) \
 +  -L../proxy \
$(EOLIST)
 
 #
 @@ -224,6 +227,7 @@
@libc.imp \
@aprlib.imp \
@httpd.imp \
 +  @mod_proxy.imp \
$(EOLIST)
 
 #
>>> 
>>> The first 2 extra lines allow the compiler to find extra headers, the 3rd 
>>> allows the linker to locate mod_proxy.imp.
>>> 
>>> Please review and apply this if it seems reasonable.
>>> 
>>> Norm
>>> 
>> 
> 
>

Re: svn commit: r1729208 - in /httpd/httpd/trunk/modules: proxy/proxy_util.c ssl/ssl_engine_io.c

2016-02-11 Thread Stefan Eissing


> Am 10.02.2016 um 20:09 schrieb Ruediger Pluem :
> 
> 
> 
> On 02/08/2016 05:50 PM, ic...@apache.org wrote:
>> [...]#ifdef HAVE_TLSEXT
>> +#ifdef HAVE_TLS_ALPN
>> +alpn_note = apr_table_get(c->notes, "proxy-request-alpn-protos");
>> +if (alpn_note) {
>> +char *protos, *s, *p, *last;
>> +apr_size_t len;
>> +
>> +s = protos = apr_pcalloc(c->pool, strlen(alpn_note)+1);
>> +p = apr_pstrdup(c->pool, alpn_note);
>> +while ((p = apr_strtok(p, ", ", ))) {
>> +len = last - p - (*last? 1 : 0); 
>> +if (len > 255) {
>> +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO()
>> +  "ALPN proxy protocol identifier too long: 
>> %s",
>> +  p);
>> +ssl_log_ssl_error(SSLLOG_MARK, APLOG_ERR, server);
>> +return APR_EGENERAL;
>> +}
>> +*s++ = (unsigned char)len;
>> +while (len--) {
>> +*s++ = *p++;
>> +}
>> +p = last;
> 
> Why not p = NULL as it should be for subsequent calls of apr_strtok?

Matter of taste. If code is more readable to everyone using NULL, that is fine 
with me.

Changed in r1729782.

Stefan

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

2016-02-11 Thread Yann Ylavic

On Thu, Feb 11, 2016 at 3:14 PM, Yann Ylavic  wrote:
> On Thu, Feb 11, 2016 at 3:10 PM, Ruediger Pluem  wrote:
>>
>> conn->ssl_hostname might be allocated from conn->scpool.
>> So the pointer might be invalid after socket_cleanup(conn). So you need to 
>> apr_pstrdup it first.
>> No real good idea which pool to use here.
>
> Oh, correct!
>
>> Probably create a temp subpool of conn->pool,
>> strdup, after socket_cleanup dup with conn->scpool and destroy tmp pool.
>
> Yes, possibly overkill, I have to find something else...

Maybe r1729847 is fine?

>
> Regards,
> Yann.

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

2016-02-11 Thread Stefan Eissing

Works in my cases.

> Am 11.02.2016 um 16:00 schrieb Yann Ylavic :
> 
> On Thu, Feb 11, 2016 at 3:14 PM, Yann Ylavic  wrote:
>> On Thu, Feb 11, 2016 at 3:10 PM, Ruediger Pluem  wrote:
>>> 
>>> conn->ssl_hostname might be allocated from conn->scpool.
>>> So the pointer might be invalid after socket_cleanup(conn). So you need to 
>>> apr_pstrdup it first.
>>> No real good idea which pool to use here.
>> 
>> Oh, correct!
>> 
>>> Probably create a temp subpool of conn->pool,
>>> strdup, after socket_cleanup dup with conn->scpool and destroy tmp pool.
>> 
>> Yes, possibly overkill, I have to find something else...
> 
> Maybe r1729847 is fine?
> 
>> 
>> Regards,
>> Yann.

FYI: Backport of mod_proxy_hcheck

2016-02-11 Thread Jim Jagielski

I am sending a trial balloon up regarding the viability
of proposing mod_proxy_hcheck be backported to 2.4.x...

If this sounds like a Good Idea, I will work on said
proposal.

Re: Replace feather

2016-02-11 Thread Stefan Eissing

+1

> Am 11.02.2016 um 18:56 schrieb Jim Jagielski :
> 
> I was wondering about whether we should update the feather[1] with the new 
> one...
> I can do it...
> 
> 1. https://httpd.apache.org/images/httpd_logo_wide_new.png
> --
> Sent via Pony Mail for dev@httpd.apache.org. 
> View this email online at:
> https://pony-poc.apache.org/list.html?dev@httpd.apache.org

Re: collaboration request - apache server automation testing with swat tool

2016-02-11 Thread Alexey Melezhik

Hi !  I have got a few comments , questions concerning this topic, thanks
for everybody! though still have idea if Apache devs are interested in new
testing framework ? It is hard to keep moving doubting if such tool could
be of interest for someone else beside  me  ) , so give me a sign please :)
If I don't waist my time.

Thanks.


пятница, 5 февраля 2016 г. пользователь Jim Jagielski написал:

> Personally, I like the idea of having another framework;
> the current one is OK but somewhat "painful" to update.
>
> I wonder how possible it would be to transcode the old tests
> to Swat? We could then provide for 2 testing frameworks, one
> developed by the ASF and the other external and 3rd party.
>
>
> > On Feb 1, 2016, at 5:23 AM, Alexey Melezhik  > wrote:
> >
> > Here the list of existed issues I was able to automate tests for:
> >
> > vagrant@Debian-jessie-amd64-netboot:~/my/apache-swat$ ls -1 | grep -P
> '\d'
> > 44221
> > 46751
> > 58789
> > 58828
> > 58854
> >
> >
> > I have informed developers at https://bz.apache.org/bugzilla/ about
> > these, so they rely upon them. Or you have some pre-release testing,
> > so run all of these in a whole chunk?
> >
> > Regards
> >
> > Alexey
> >
> > PS chaining issues / tests listing  as always -
> > https://github.com/melezhik/apache-swat
> >
> > PS2 it'd be could to verify tests as well against "bleeding edge"
> > apache version gets installed from SCM, but I don't know how to do
> > this.
> > Currently I use http://httpd.apache.org/download.cgi ( last stable
> release )
> >
> >
> >
> > 2016-01-30 21:36 GMT+03:00 Alexey Melezhik  >:
> >> Hi Bill!
> >>
> >> I have started to assemble swat tests  for apache2 issues coming from
> >> https://bz.apache.org/bugzilla
> >>
> >> And this the first one -
> https://bz.apache.org/bugzilla/show_bug.cgi?id=44221 ,
> >>
> >> Test suite is failed for the moment :
> >>
> >>
> >> vagrant@Debian-jessie-amd64-netboot:~/my/apache-swat$ swat -t 44221
> >> /home/vagrant/.swat/.cache/384/prove/44221/foo.baz/00.GET.t ...
> >> ok 1 - GET 127.0.0.1/44221/foo.baz succeeded
> >> # http headers saved to
> /home/vagrant/.swat/.cache/384/prove/52jLAo76YZ.hdr
> >> # body saved to /home/vagrant/.swat/.cache/384/prove/52jLAo76YZ
> >> ok 2 - output match '200 OK'
> >> 1..2
> >> ok
> >> /home/vagrant/.swat/.cache/384/prove/44221/FOO.bar/00.GET.t ...
> >> ok 1 - GET 127.0.0.1/44221/FOO.bar succeeded
> >> # http headers saved to
> /home/vagrant/.swat/.cache/384/prove/DvEZnO6ALe.hdr
> >> # body saved to /home/vagrant/.swat/.cache/384/prove/DvEZnO6ALe
> >> ok 2 - output match '200 OK'
> >> ok 3 - output match /Location: \S+/
> >> ok 4 - 'Location: http://127.0.0.1/44221/foo.bar' match 'foo.bar'
> >> 1..4
> >> ok
> >> /home/vagrant/.swat/.cache/384/prove/44221/foo.BAR/00.GET.t ...
> >> ok 1 - GET 127.0.0.1/44221/foo.BAR succeeded
> >> # http headers saved to
> /home/vagrant/.swat/.cache/384/prove/bWQ1Sbl0YZ.hdr
> >> # body saved to /home/vagrant/.swat/.cache/384/prove/bWQ1Sbl0YZ
> >> ok 2 - output match '200 OK'
> >> ok 3 - output match /Location: \S+/
> >> ok 4 - 'Location: http://127.0.0.1/44221/foo.bar' match 'foo.bar'
> >> 1..4
> >> ok
> >> /home/vagrant/.swat/.cache/384/prove/44221/foo.bar/00.GET.t ...
> >> ok 1 - GET 127.0.0.1/44221/foo.bar succeeded
> >> # http headers saved to
> /home/vagrant/.swat/.cache/384/prove/Jd_hlo7Qwv.hdr
> >> # body saved to /home/vagrant/.swat/.cache/384/prove/Jd_hlo7Qwv
> >> ok 2 - output match '200 OK'
> >> 1..2
> >> ok
> >> /home/vagrant/.swat/.cache/384/prove/44221/foo.html/00.GET.t ..
> >> ok 1 - GET 127.0.0.1/44221/foo.html succeeded
> >> # http headers saved to
> /home/vagrant/.swat/.cache/384/prove/tW2L511eym.hdr
> >> # body saved to /home/vagrant/.swat/.cache/384/prove/tW2L511eym
> >> ok 2 - output match /HTTP\/(\S+) (\d+) \S+/
> >> not ok 3 - 'HTTP/1.1 300 Multiple Choices' match /404 /
> >>
> >> #   Failed test ''HTTP/1.1 300 Multiple Choices' match /404 /'
> >> #   at /usr/local/share/perl/5.20.2/swat.pm line 218.
> >> not ok 4 - output match 'Not Found'
> >>
> >> #   Failed test 'output match 'Not Found''
> >> #   at /usr/local/share/perl/5.20.2/swat.pm line 218.
> >> 1..4
> >> # Looks like you failed 2 tests of 4.
> >> Dubious, test returned 2 (wstat 512, 0x200)
> >> Failed 2/4 subtests
> >>
> >> Test Summary Report
> >> ---
> >> /home/vagrant/.swat/.cache/384/prove/44221/foo.html/00.GET.t (Wstat:
> >> 512 Tests: 4 Failed: 2)
> >>  Failed tests:  3-4
> >>  Non-zero exit status: 2
> >> Files=5, Tests=16,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.27 cusr
> >> 0.00 csys =  0.30 CPU)
> >> Result: FAIL
> >>
> >> ...
> >>
> >> Ok, this is just the beginning ;-))) , watch soon updates at -
> >> https://github.com/melezhik/apache-swat
> >>
> >> 2016-01-29 20:44 GMT+03:00 William A Rowe Jr  >:
> >>> On Fri, Jan 29, 2016 at 6:35 AM, Alexey Melezhik  > wrote:

Re: ABI report

2016-02-11 Thread Ponomarenko Andrey

09.02.2016, 15:02, "Jeff Trawick":On Sun, Feb 7, 2016 at 2:32 AM, Ponomarenko Andrey wrote:Hello,  I've started to maintain binary compatibility report for the recent versions of the httpd: http://abi-laboratory.pro/tracker/timeline/httpd/  The report is updated every other day. The report for the latest version from git is also there. Hope this helps Linux maintainers to be aware of ABI changes and added/removed symbols.  Thank you. Perhaps there could be a way to configure a message related to the intended breakage between 2.2.last and 2.4.first, since that is interesting from an API migration standpoint.  (Link to https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html) Done: http://abi-laboratory.pro/tracker/timeline/httpd/#v2.4.1 Please let me know if you want to change this message or add some notes for other versions. Thank you.

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

2016-02-11 Thread Ruediger Pluem



On 02/11/2016 02:46 PM, yla...@apache.org wrote:
> Author: ylavic
> Date: Thu Feb 11 13:46:39 2016
> New Revision: 1729826
> 
> URL: http://svn.apache.org/viewvc?rev=1729826=rev
> Log:
> mod_proxy: Play/restore the TLS-SNI on new backend connections which
> had to be issued because the remote closed the previous/reusable one
> during idle (keep-alive) time.
> 
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/modules/proxy/proxy_util.c
> 
> Modified: httpd/httpd/trunk/CHANGES
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1729826=1729825=1729826=diff
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Thu Feb 11 13:46:39 2016
> @@ -1,6 +1,10 @@
>   -*- coding: utf-8 
> -*-
>  Changes with Apache 2.5.0
>  
> +  *) mod_proxy: Play/restore the TLS-SNI on new backend connections which
> + had to be issued because the remote closed the previous/reusable one
> + during idle (keep-alive) time.  [Yann Ylavic]
> +
>*) mod_proxy_http2: new experimental http2 proxy module for h2: and h2c: 
> proxy
>   urls. Uses, so far, one connection per request, reuses connections.
>
> 
> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1729826=1729825=1729826=diff
> ==
> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Thu Feb 11 13:46:39 2016
> @@ -2717,12 +2717,18 @@ PROXY_DECLARE(int) ap_proxy_connect_back
>  
>  if (conn->sock) {
>  if (!(connected = ap_proxy_is_socket_connected(conn->sock))) {
> -/* FIXME: this loses conn->ssl_hostname and it will not be
> - * restablished before the SSL connection is made -> no SNI! */
> +/* This clears conn->scpool (and associated data), so backup and
> + * restore any ssl_hostname for this connection set earlier by
> + * ap_proxy_determine_connection().
> + */
> +const char *ssl_hostname = conn->ssl_hostname;

conn->ssl_hostname might be allocated from conn->scpool.
So the pointer might be invalid after socket_cleanup(conn). So you need to 
apr_pstrdup it first.
No real good idea which pool to use here. Probably create a temp subpool of 
conn->pool,
strdup, after socket_cleanup dup with conn->scpool and destroy tmp pool.

> +
>  socket_cleanup(conn);
>  ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(00951)
>   "%s: backend socket is disconnected.",
>   proxy_function);
> +
> +conn->ssl_hostname = apr_pstrdup(conn->scpool, ssl_hostname);
>  }
>  }
>  while ((backend_addr || conn->uds_path) && !connected) {
> 
> 
> 

Regards

Rüdiger

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

2016-02-11 Thread Stefan Eissing


> Am 11.02.2016 um 15:10 schrieb Ruediger Pluem :
> 
> 
> 
> On 02/11/2016 02:46 PM, yla...@apache.org wrote:
>> Author: ylavic
>> Date: Thu Feb 11 13:46:39 2016
>> New Revision: 1729826
>> 
>> URL: http://svn.apache.org/viewvc?rev=1729826=rev
>> Log:
>> mod_proxy: Play/restore the TLS-SNI on new backend connections which
>> had to be issued because the remote closed the previous/reusable one
>> during idle (keep-alive) time.
>> 
>> Modified:
>>httpd/httpd/trunk/CHANGES
>>httpd/httpd/trunk/modules/proxy/proxy_util.c
>> 
>> Modified: httpd/httpd/trunk/CHANGES
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1729826=1729825=1729826=diff
>> ==
>> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
>> +++ httpd/httpd/trunk/CHANGES [utf-8] Thu Feb 11 13:46:39 2016
>> @@ -1,6 +1,10 @@
>>  -*- coding: utf-8 
>> -*-
>> Changes with Apache 2.5.0
>> 
>> +  *) mod_proxy: Play/restore the TLS-SNI on new backend connections which
>> + had to be issued because the remote closed the previous/reusable one
>> + during idle (keep-alive) time.  [Yann Ylavic]
>> +
>>   *) mod_proxy_http2: new experimental http2 proxy module for h2: and h2c: 
>> proxy
>>  urls. Uses, so far, one connection per request, reuses connections.
>> 
>> 
>> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1729826=1729825=1729826=diff
>> ==
>> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
>> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Thu Feb 11 13:46:39 2016
>> @@ -2717,12 +2717,18 @@ PROXY_DECLARE(int) ap_proxy_connect_back
>> 
>> if (conn->sock) {
>> if (!(connected = ap_proxy_is_socket_connected(conn->sock))) {
>> -/* FIXME: this loses conn->ssl_hostname and it will not be
>> - * restablished before the SSL connection is made -> no SNI! */
>> +/* This clears conn->scpool (and associated data), so backup and
>> + * restore any ssl_hostname for this connection set earlier by
>> + * ap_proxy_determine_connection().
>> + */
>> +const char *ssl_hostname = conn->ssl_hostname;
> 
> conn->ssl_hostname might be allocated from conn->scpool.
> So the pointer might be invalid after socket_cleanup(conn). So you need to 
> apr_pstrdup it first.
> No real good idea which pool to use here. Probably create a temp subpool of 
> conn->pool,
> strdup, after socket_cleanup dup with conn->scpool and destroy tmp pool.

I only dup'ed it once into a stack pointer. So, I used the r->pool for that. 
> 
>> +
>> socket_cleanup(conn);
>> ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(00951)
>>  "%s: backend socket is disconnected.",
>>  proxy_function);
>> +
>> +conn->ssl_hostname = apr_pstrdup(conn->scpool, ssl_hostname);
>> }
>> }
>> while ((backend_addr || conn->uds_path) && !connected) {
>> 
>> 
>> 
> 
> Regards
> 
> Rüdiger

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

2016-02-11 Thread Yann Ylavic

On Thu, Feb 11, 2016 at 3:10 PM, Ruediger Pluem  wrote:
>
> conn->ssl_hostname might be allocated from conn->scpool.
> So the pointer might be invalid after socket_cleanup(conn). So you need to 
> apr_pstrdup it first.
> No real good idea which pool to use here.

Oh, correct!

> Probably create a temp subpool of conn->pool,
> strdup, after socket_cleanup dup with conn->scpool and destroy tmp pool.

Yes, possibly overkill, I have to find something else...

Regards,
Yann.

Re: mod_proxy_http2

2016-02-11 Thread Stefan Eissing

Thanks Yann. My test cases still work, so all is fine.

> Am 11.02.2016 um 14:55 schrieb Yann Ylavic :
> 
> On Tue, Feb 9, 2016 at 3:42 PM, Yann Ylavic  wrote:
>> On Mon, Feb 8, 2016 at 6:07 PM, Stefan Eissing
>>  wrote:
>>> 
>>> One thing: the ssl_hostname that is used for SNI by the generic proxy utils 
>>> seems to get lost when the socket needs to reset and is then not available 
>>> on the next connect. That should affect mod_proxy_http as far as I can 
>>> tell. Maybe someone with more experience in that module wants to take a 
>>> look.
>> 
>> This is intended (for http/1 at least), why is it an issue?
>> When mod_proxy closes the backend connection, it indeed clears any
>> associated SNI.
> 
> OK, I see now, hopefully fixed in r1729826 (backport to 2.4.x candidate...).
> I also removed mod_proxy_http2 workaround code in r1729830, please let
> me know if it still does not work.
> 
> Regards,
> Yann.

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

2016-02-11 Thread Yann Ylavic

On Thu, Feb 11, 2016 at 3:12 PM, Stefan Eissing
 wrote:
>
>> Am 11.02.2016 um 15:10 schrieb Ruediger Pluem :
>>
>>
>> conn->ssl_hostname might be allocated from conn->scpool.
>> So the pointer might be invalid after socket_cleanup(conn). So you need to 
>> apr_pstrdup it first.
>> No real good idea which pool to use here. Probably create a temp subpool of 
>> conn->pool,
>> strdup, after socket_cleanup dup with conn->scpool and destroy tmp pool.
>
> I only dup'ed it once into a stack pointer. So, I used the r->pool for that.

But we don't have an 'r' in ap_proxy_connect_backend(), maybe a new
_ex() function is needed.

Re: mod_proxy_http2

2016-02-11 Thread Yann Ylavic

On Tue, Feb 9, 2016 at 3:42 PM, Yann Ylavic  wrote:
> On Mon, Feb 8, 2016 at 6:07 PM, Stefan Eissing
>  wrote:
>>
>> One thing: the ssl_hostname that is used for SNI by the generic proxy utils 
>> seems to get lost when the socket needs to reset and is then not available 
>> on the next connect. That should affect mod_proxy_http as far as I can tell. 
>> Maybe someone with more experience in that module wants to take a look.
>
> This is intended (for http/1 at least), why is it an issue?
> When mod_proxy closes the backend connection, it indeed clears any
> associated SNI.

OK, I see now, hopefully fixed in r1729826 (backport to 2.4.x candidate...).
I also removed mod_proxy_http2 workaround code in r1729830, please let
me know if it still does not work.

Regards,
Yann.

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

2016-02-11 Thread Ruediger Pluem



On 02/11/2016 03:57 PM, yla...@apache.org wrote:
> Author: ylavic
> Date: Thu Feb 11 14:57:04 2016
> New Revision: 1729847
> 
> URL: http://svn.apache.org/viewvc?rev=1729847=rev
> Log:
> mod_proxy: follow up to r1729826: really copy conn->ssl_hostname.
> 
> Modified:
> httpd/httpd/trunk/modules/proxy/proxy_util.c

In general this looks fine. We only run in trouble if something provided in the 
Host header is longer then
PROXY_WORKER_MAX_HOSTNAME_SIZE (in case of ProxyPreserveHost on). Then we loose 
the SNI hostname on these requests.
Probably never happens, but could be fun to debug if it happens :-).
So probably HUGE_STRING_LEN would be better, but a huge waste of stack 
resources in most cases for sure.

Regards

Rüdiger

> 
> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1729847=1729846=1729847=diff
> ==
> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Thu Feb 11 14:57:04 2016
> @@ -2721,14 +2721,20 @@ PROXY_DECLARE(int) ap_proxy_connect_back
>   * restore any ssl_hostname for this connection set earlier by
>   * ap_proxy_determine_connection().
>   */
> -const char *ssl_hostname = conn->ssl_hostname;
> +char ssl_hostname[PROXY_WORKER_MAX_HOSTNAME_SIZE];
> +if (!conn->ssl_hostname || PROXY_STRNCPY(ssl_hostname,
> + conn->ssl_hostname)) {
> +ssl_hostname[0] = '\0';
> +}
>  
>  socket_cleanup(conn);
>  ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(00951)
>   "%s: backend socket is disconnected.",
>   proxy_function);
>  
> -conn->ssl_hostname = apr_pstrdup(conn->scpool, ssl_hostname);
> +if (ssl_hostname[0]) {
> +conn->ssl_hostname = apr_pstrdup(conn->scpool, ssl_hostname);
> +}
>  }
>  }
>  while ((backend_addr || conn->uds_path) && !connected) {
> 
> 
>

Re: Shouldn't ap_get_remote_host use req->useragent_addr?

2016-02-11 Thread William A Rowe Jr

On Thu, Jan 7, 2016 at 9:06 AM, Eric Covener  wrote:

> On Thu, Jan 7, 2016 at 9:25 AM, Jan Kaluža  wrote:
> > When httpd is running behind a reverse proxy and mod_remoteip is
> configured,
> > the correct client IP is logged (using %a in the LogFormat), but the
> proxy
> > IP is used by 'Require host .mydomain.net'. I would expect the host
> based on
> > IP provided by mod_remoteip to be used here.
> >
> > Is this expected behaviour? Maybe the ap_get_remote_host method should
> use
> > req->useragent_addr instead of conn->client_addr to obtain the
> REMOTE_HOST.
>
> what about "Require ip ..."?
>

I agree that require host should track to the same entity as the require ip,
which means the behavior right now is incorrect.

There could be a Require conn-ip / conn-host that looks "around" the request
based user agent down to the connection level user agent (proxy) address.

But this mismatch is unnecessarily confusing, and what the original remoteip
module was meant to avoid.

Re: FYI: Backport of mod_proxy_hcheck

2016-02-11 Thread Eric Covener

On Thu, Feb 11, 2016 at 10:25 AM, Jim Jagielski  wrote:
> I am sending a trial balloon up regarding the viability
> of proposing mod_proxy_hcheck be backported to 2.4.x...
>
> If this sounds like a Good Idea, I will work on said
> proposal.

Anything controversial in the final stuff? Only thing ringing a bell
is  the meaning of those status flags?

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

Re: FYI: Backport of mod_proxy_hcheck

2016-02-11 Thread Stefan Eissing

I'am all for backporting nice things, however I did not follow all discussions 
and cannot judge the impact.

> Am 11.02.2016 um 16:25 schrieb Jim Jagielski :
> 
> I am sending a trial balloon up regarding the viability
> of proposing mod_proxy_hcheck be backported to 2.4.x...
> 
> If this sounds like a Good Idea, I will work on said
> proposal.

Re: FYI: Backport of mod_proxy_hcheck

2016-02-11 Thread Jim Jagielski


> On Feb 11, 2016, at 10:27 AM, Eric Covener  wrote:
> 
> On Thu, Feb 11, 2016 at 10:25 AM, Jim Jagielski  wrote:
>> I am sending a trial balloon up regarding the viability
>> of proposing mod_proxy_hcheck be backported to 2.4.x...
>> 
>> If this sounds like a Good Idea, I will work on said
>> proposal.
> 
> Anything controversial in the final stuff? Only thing ringing a bell
> is  the meaning of those status flags?
> 

Better documented in the new reverse-proxy HowTo guide.

Re: svn commit: r1729901 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

2016-02-11 Thread Rainer Jung


I fixed two minor compilation failures, but one type of failure remains:

.../server/core.c: In function 'ap_get_remote_host':
.../server/core.c:959:17: error: cannot take address of bit-field 
'double_reverse'
 do_double_reverse(>double_reverse, 
conn->remote_host,

 ^
.../server/core.c:974:9: error: cannot take address of bit-field 
'double_reverse'

 do_double_reverse(>double_reverse, conn->remote_host,
 ^

Regards,

Rainer

Am 11.02.2016 um 22:58 schrieb wr...@apache.org:

Author: wrowe
Date: Thu Feb 11 21:58:45 2016
New Revision: 1729901

URL: http://svn.apache.org/viewvc?rev=1729901=rev
Log:
Introduce an ap_get_useragent_host() accessor to replace the old
ap_get_remote_host() in most applications, but preserve the original
behavior for all ap_get_remote_host() consumers (mostly, because we
don't have the request_rec in the first place, and also to avoid any
unintended consequences).

This accessor continues to store the remote_host of connection based
uesr agents within the conn_rec for optimization.  Only where some
other module modifies the useragent_addr will we perform a per-request
query of the remote_host.

(Committed previously, but backed out due to unrelated core.c changes)

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/include/ap_mmn.h
 httpd/httpd/trunk/include/http_core.h
 httpd/httpd/trunk/include/httpd.h
 httpd/httpd/trunk/server/core.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1729901=1729900=1729901=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Thu Feb 11 21:58:45 2016
@@ -1,6 +1,11 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.0

+  *) core: Track the useragent_host per-request when mod_remoteip or similar
+ modules track a per-request useragent_ip.  Modules should be updated
+ to inquire for ap_get_useragent_host() in place of ap_get_remote_host().
+ [William Rowe]
+
*) mod_proxy: Play/restore the TLS-SNI on new backend connections which
   had to be issued because the remote closed the previous/reusable one
   during idle (keep-alive) time.  [Yann Ylavic]

Modified: httpd/httpd/trunk/include/ap_mmn.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1729901=1729900=1729901=diff
==
--- httpd/httpd/trunk/include/ap_mmn.h (original)
+++ httpd/httpd/trunk/include/ap_mmn.h Thu Feb 11 21:58:45 2016
@@ -500,6 +500,8 @@
   * 20150222.9 (2.5.0-dev)  Add epxr_hander to core_dir_config.
   * 20150222.10 (2.5.0-dev) Add new ap_update_child_status...() methods,
   * add protocol to worker_score in scoreboard.h
+ * 20150222.11 (2.5.0-dev) Split useragent_host from the conn_rec into
+ * the request_rec, with ap_get_useragent_host()
   */

  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
@@ -507,7 +509,7 @@
  #ifndef MODULE_MAGIC_NUMBER_MAJOR
  #define MODULE_MAGIC_NUMBER_MAJOR 20150222
  #endif
-#define MODULE_MAGIC_NUMBER_MINOR 10 /* 0...n */
+#define MODULE_MAGIC_NUMBER_MINOR 11 /* 0...n */

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

Modified: httpd/httpd/trunk/include/http_core.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_core.h?rev=1729901=1729900=1729901=diff
==
--- httpd/httpd/trunk/include/http_core.h (original)
+++ httpd/httpd/trunk/include/http_core.h Thu Feb 11 21:58:45 2016
@@ -159,6 +159,32 @@ AP_DECLARE(int) ap_allow_overrides(reque
  AP_DECLARE(const char *) ap_document_root(request_rec *r);

  /**
+ * Lookup the remote user agent's DNS name or IP address
+ * @ingroup get_remote_hostname
+ * @param req The current request
+ * @param type The type of lookup to perform.  One of:
+ * 
+ * REMOTE_HOST returns the hostname, or NULL if the hostname
+ * lookup fails.  It will force a DNS lookup according to the
+ * HostnameLookups setting.
+ * REMOTE_NAME returns the hostname, or the dotted quad if the
+ * hostname lookup fails.  It will force a DNS lookup according
+ * to the HostnameLookups setting.
+ * REMOTE_NOLOOKUP is like REMOTE_NAME except that a DNS lookup is
+ * never forced.
+ * REMOTE_DOUBLE_REV will always force a DNS lookup, and also force
+ *   a double reverse lookup, regardless of the HostnameLookups
+ *   setting.  The result is the (double reverse checked)
+ *   hostname, or NULL if any of the lookups fail.
+ * 
+ * @param str_is_ip unless NULL is passed, this

Re: svn commit: r1729901 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

2016-02-11 Thread William A Rowe Jr

I was just about to do the same, but revert and recommit just to simplify
the (anticipated) later backport.  The bitfield is a bugger.

Apparently my make clean; make wasn't building the source tree
I thought it was, sigh...

Bill

On Thu, Feb 11, 2016 at 6:20 PM, Rainer Jung 
wrote:

> I fixed two minor compilation failures, but one type of failure remains:
>
> .../server/core.c: In function 'ap_get_remote_host':
> .../server/core.c:959:17: error: cannot take address of bit-field
> 'double_reverse'
>  do_double_reverse(>double_reverse,
> conn->remote_host,
>  ^
> .../server/core.c:974:9: error: cannot take address of bit-field
> 'double_reverse'
>  do_double_reverse(>double_reverse, conn->remote_host,
>  ^
>
> Regards,
>
> Rainer
>
>
> Am 11.02.2016 um 22:58 schrieb wr...@apache.org:
>
>> Author: wrowe
>> Date: Thu Feb 11 21:58:45 2016
>> New Revision: 1729901
>>
>> URL: http://svn.apache.org/viewvc?rev=1729901=rev
>> Log:
>> Introduce an ap_get_useragent_host() accessor to replace the old
>> ap_get_remote_host() in most applications, but preserve the original
>> behavior for all ap_get_remote_host() consumers (mostly, because we
>> don't have the request_rec in the first place, and also to avoid any
>> unintended consequences).
>>
>> This accessor continues to store the remote_host of connection based
>> uesr agents within the conn_rec for optimization.  Only where some
>> other module modifies the useragent_addr will we perform a per-request
>> query of the remote_host.
>>
>> (Committed previously, but backed out due to unrelated core.c changes)
>>
>> Modified:
>>  httpd/httpd/trunk/CHANGES
>>  httpd/httpd/trunk/include/ap_mmn.h
>>  httpd/httpd/trunk/include/http_core.h
>>  httpd/httpd/trunk/include/httpd.h
>>  httpd/httpd/trunk/server/core.c
>>
>> Modified: httpd/httpd/trunk/CHANGES
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1729901=1729900=1729901=diff
>>
>> ==
>> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
>> +++ httpd/httpd/trunk/CHANGES [utf-8] Thu Feb 11 21:58:45 2016
>> @@ -1,6 +1,11 @@
>>-*- coding:
>> utf-8 -*-
>>   Changes with Apache 2.5.0
>>
>> +  *) core: Track the useragent_host per-request when mod_remoteip or
>> similar
>> + modules track a per-request useragent_ip.  Modules should be updated
>> + to inquire for ap_get_useragent_host() in place of
>> ap_get_remote_host().
>> + [William Rowe]
>> +
>> *) mod_proxy: Play/restore the TLS-SNI on new backend connections
>> which
>>had to be issued because the remote closed the previous/reusable
>> one
>>during idle (keep-alive) time.  [Yann Ylavic]
>>
>> Modified: httpd/httpd/trunk/include/ap_mmn.h
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1729901=1729900=1729901=diff
>>
>> ==
>> --- httpd/httpd/trunk/include/ap_mmn.h (original)
>> +++ httpd/httpd/trunk/include/ap_mmn.h Thu Feb 11 21:58:45 2016
>> @@ -500,6 +500,8 @@
>>* 20150222.9 (2.5.0-dev)  Add epxr_hander to core_dir_config.
>>* 20150222.10 (2.5.0-dev) Add new ap_update_child_status...() methods,
>>* add protocol to worker_score in scoreboard.h
>> + * 20150222.11 (2.5.0-dev) Split useragent_host from the conn_rec into
>> + * the request_rec, with ap_get_useragent_host()
>>*/
>>
>>   #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
>> @@ -507,7 +509,7 @@
>>   #ifndef MODULE_MAGIC_NUMBER_MAJOR
>>   #define MODULE_MAGIC_NUMBER_MAJOR 20150222
>>   #endif
>> -#define MODULE_MAGIC_NUMBER_MINOR 10 /* 0...n */
>> +#define MODULE_MAGIC_NUMBER_MINOR 11 /* 0...n */
>>
>>   /**
>>* Determine if the server's current MODULE_MAGIC_NUMBER is at least a
>>
>> Modified: httpd/httpd/trunk/include/http_core.h
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_core.h?rev=1729901=1729900=1729901=diff
>>
>> ==
>> --- httpd/httpd/trunk/include/http_core.h (original)
>> +++ httpd/httpd/trunk/include/http_core.h Thu Feb 11 21:58:45 2016
>> @@ -159,6 +159,32 @@ AP_DECLARE(int) ap_allow_overrides(reque
>>   AP_DECLARE(const char *) ap_document_root(request_rec *r);
>>
>>   /**
>> + * Lookup the remote user agent's DNS name or IP address
>> + * @ingroup get_remote_hostname
>> + * @param req The current request
>> + * @param type The type of lookup to perform.  One of:
>> + * 
>> + * REMOTE_HOST returns the hostname, or NULL if the hostname
>> + * lookup fails.  It will force a DNS lookup according
>> to the
>> + * HostnameLookups setting.
>> + * REMOTE_NAME returns the hostname, or

Re: Support for OpenSSL 1.1.0

2016-02-11 Thread Rainer Jung

The list is getting shorter. The test suite currently only shows a few 
failures due to the missing "talking http on https" support.


Am 09.02.2016 um 11:20 schrieb Rainer Jung:


Open problems:

1) HTTP on HTTPS

OpenSSL 1.1.0 currently doesn't support the "HTTP spoken on HTTPS port"
error. The code to detect HTTP was removed due to a major rewrite of the
state engine. The OpenSSL project is willing to review patches for
reintroducing the feature there but currently doesn't plan to work on it
themselves.


I'll try tackling this next. Nut sure how well it will go.


2) Renegotiation

It needs to be implemented differently. The OpenSSL project suggest to
try reading application data until the renegotiation has finished. I
committed some rather ugly code that does loop waiting for reneg, but it
has a couple of problems:


Still using poll, but better state tracking now.


a) it will not work for EC or DH ciphers. Some opaque structure element
in the ssl struct is already set and confuses the state machine. I hope
to get some helpful feedback from the OpenSSL project for this.


Still open.


5) ssl_engine_kernel.c

In ssl_callback_Info() the explicit state constants
SSL3_ST_SR_CLNT_HELLO_A and SSL23_ST_SR_CLNT_HELLO_A are used which no
longer exist. I can't find obvious replacements in the list of new state
constants:

2100 int state = SSL_get_state((SSL *)ssl);
2101
2102 if (state == SSL3_ST_SR_CLNT_HELLO_A
2103 || state == SSL23_ST_SR_CLNT_HELLO_A) {
2104 scr->reneg_state = RENEG_ABORT;
2105 ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02042)
2106   "rejecting client initiated renegotiation");
2107 }


That shouldn't be too hard. Will look into it.

Regards,

Rainer

Re: svn commit: r1729901 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

2016-02-11 Thread William A Rowe Jr

On Thu, Feb 11, 2016 at 6:20 PM, Rainer Jung 
wrote:

> one type of failure remains:
>
> .../server/core.c: In function 'ap_get_remote_host':
> .../server/core.c:959:17: error: cannot take address of bit-field
> 'double_reverse'
>  do_double_reverse(>double_reverse,
> conn->remote_host,
>  ^
> .../server/core.c:974:9: error: cannot take address of bit-field
> 'double_reverse'
>  do_double_reverse(>double_reverse, conn->remote_host,
>  ^
>

Funny enough, because this is inline, the assignment of an int to an int :2
raises no truncation warning; the entire return {val} is in the domain
1..-1 :)

These should all be ready for further review against trunk and 2.4.x.  I can
spend time Sunday reviewing any new edge cases specific to trunk, the
grep pattern "[>_]remote_host" was pretty efficient at tracking these down.

Bill

Re: svn commit: r1729876 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h server/core.c

2016-02-11 Thread Eric Covener

>> --- httpd/httpd/branches/2.4.x/include/ap_mmn.h (original)
>> +++ httpd/httpd/branches/2.4.x/include/ap_mmn.h Thu Feb 11 19:06:16 2016
>> @@ -457,6 +457,7 @@
>>   *  ap_get_protocol(). Add
>> HTTP_MISDIRECTED_REQUEST.
>>   *  Added ap_parse_token_list_strict() to httpd.h
>>   * 20120211.52 (2.4.17-dev) Add master conn_rec* member in conn_rec.
>> + * 20120211.53 (2.4.17-dev) Add epxr_hander to core_dir_config.
>
>
> Just a gravity wave effect in the space-time continuum today, I expect?  :)

r1729922.

> Probably want to review your commits to ensure no others are mislabeled
> two versions back in time.

sigh.

Re: svn commit: r1729876 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h server/core.c

2016-02-11 Thread William A Rowe Jr

On Thu, Feb 11, 2016 at 1:06 PM,  wrote:

> Author: jim
> Date: Thu Feb 11 19:06:16 2016
> New Revision: 1729876
>
> URL: http://svn.apache.org/viewvc?rev=1729876=rev
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_mmn.h?rev=1729876=1729875=1729876=diff
>
> ==
> --- httpd/httpd/branches/2.4.x/include/ap_mmn.h (original)
> +++ httpd/httpd/branches/2.4.x/include/ap_mmn.h Thu Feb 11 19:06:16 2016
> @@ -457,6 +457,7 @@
>   *  ap_get_protocol(). Add
> HTTP_MISDIRECTED_REQUEST.
>   *  Added ap_parse_token_list_strict() to httpd.h
>   * 20120211.52 (2.4.17-dev) Add master conn_rec* member in conn_rec.
> + * 20120211.53 (2.4.17-dev) Add epxr_hander to core_dir_config.
>

Just a gravity wave effect in the space-time continuum today, I expect?  :)

Probably want to review your commits to ensure no others are mislabeled
two versions back in time.

Re: httpd-trunk/modules/http2 gets a proxy

2016-02-11 Thread NormW


G/M Stefan,
I've specifically waited until sunup, which will hopefully mean I've got 
a clearer head.
A check of the NWGNUmakefile I sent yesterday DID have a number of bugs 
in it, all largely my fault, and some the result of doing an SVN Update 
to my local copy at the wrong time.

We'll call that the past.
Attached are the two files now guarenteed (I've checked them twice this 
morning) and can even guarentee mod_http2 builds nghtttp2 v1.7.1, which 
contains a Security Fix, CVE-2016-1544.


Process:

1. Delete /http2/NWGNUmakefile... it is not worth trying to do a diff 
against it, its innards have changed that much).


2. Add the two attached files herewith to /http2.

3. Job done.

As for making  things easier with a 'commit', I'd still make at least 
similar stuffups, whereas the ultimate 'easy' would be to wave goodbye 
to NetWare:


155+ build files and a few OS-specific files could go, your may be able 
to argue for something later than C89 as minimum standard, and so on...

...and I'm out of a job.
But equally, once changes in trunk settle out, building is fairly stable 
for months (years?) at a stretch, and there'd be nothing for my 'commit' 
to do.

Regard, and apologies for the transient trouble.
Norm


On 11/02/2016 8:31 PM, Stefan Eissing wrote:

Uhm, is there an unresolved conflict in the first file?

-Stefan

PS. You know, it *would* actually be easier if you had commit access... ;-)


Am 11.02.2016 um 03:09 schrieb NormW :

G/A Stefan,
My BBAADD. Until recently /http2 was home only to mod_http2, and to keep things 
automatic my NWGNUmakefile in there used a wildcard *.c to get the list of 
object files to build there. When the compile  failed due to added .c files I 
made a few tweaks to the NWGNU and it all linked without issue again so I 
forwarded the small tweaks. Closer reading of the list and the added .c 
revealed there are (at least) two modules now in /http2. This necessitated a 
change of the NWGNU to use a specified list of .c for a start, and removal of a 
couple of the patch lines I'd recently sent. Because other modules will be 
sharing the same dir I've renamed the original NWNUmakefile to NWGNUmod_http2 
and there is now a new NWGNUmakefile whose only job is to call the other NWGNU 
files that will eventually exist in the dir. (If all this sounds confusing it 
probably is, but by way of example see /proxy dir and note a NWGNUmakefile that 
contains a list of executables to build.)

If we are still speaking after explaining all that, the new files are attached, 
thus:
: NWGUmod_http2 which now has the list of /http2 files to build mod_http2;

: NWGNUmakefile which, FTM, has a list of modules to build, but I won't try to 
explain why the list has a double entry if there is only one (so far) to build.

Hopefully I will eventually work out a process to do away with this 
'additional' NWGNUmakefile, which would allow removal of quite a few from the 
source tree.
Apologies for the bother,
Norm

On 10/02/2016 10:34 PM, Stefan Eissing wrote:

Applied in r1729583. Thanks!


Am 08.02.2016 um 23:07 schrieb NormW :




G/M,
Recent additions to http-trunk/modules/http2 require the attached apatch to the 
http2 NetWare build file:

Index: modules/http2/NWGNUmakefile
===
--- modules/http2/NWGNUmakefile (revision 1729251)
+++ modules/http2/NWGNUmakefile (working copy)
@@ -34,6 +34,8 @@
$(NGH2SRC)/lib/ \
$(NGH2SRC)/lib/includes \
$(SERVER)/mpm/NetWare \
+   $(STDMOD)/proxy \
+   $(STDMOD)/ssl \
$(NWOS) \
$(EOLIST)

@@ -55,6 +57,7 @@
#
XLFLAGS += \
-L$(OBJDIR) \
+   -L../proxy \
$(EOLIST)

#
@@ -224,6 +227,7 @@
@libc.imp \
@aprlib.imp \
@httpd.imp \
+   @mod_proxy.imp \
$(EOLIST)

#


The first 2 extra lines allow the compiler to find extra headers, the 3rd 
allows the linker to locate mod_proxy.imp.

Please review and apply this if it seems reasonable.

Norm










#
# Declare the sub-directories to be built here
#

SUBDIRS = \
$(EOLIST)

#
# Get the 'head' of the build environment.  This includes default targets and
# paths to tools
#

include $(AP_WORK)/build/NWGNUhead.inc

#
# build this level's files

#
# Make sure all needed macro's are defined
#

#
# These directories will be at the beginning of the include list, followed by
# INCDIRS
#
XINCDIRS+= \
$(EOLIST)

#
# These flags will come after CFLAGS
#
XCFLAGS += \
$(EOLIST)

#
# These defines will come after DEFINES
#
XDEFINES+= \
$(EOLIST)

#
# These flags will be added to the link.opt file
#
XLFLAGS += \
$(EOLIST)

#
# These

Re: Shouldn't ap_get_remote_host use req->useragent_addr?

2016-02-11 Thread William A Rowe Jr

On Thu, Feb 11, 2016 at 10:14 AM, William A Rowe Jr 
wrote:

> On Thu, Jan 7, 2016 at 9:06 AM, Eric Covener  wrote:
>
>> On Thu, Jan 7, 2016 at 9:25 AM, Jan Kaluža  wrote:
>> > When httpd is running behind a reverse proxy and mod_remoteip is
>> configured,
>> > the correct client IP is logged (using %a in the LogFormat), but the
>> proxy
>> > IP is used by 'Require host .mydomain.net'. I would expect the host
>> based on
>> > IP provided by mod_remoteip to be used here.
>> >
>> > Is this expected behaviour? Maybe the ap_get_remote_host method should
>> use
>> > req->useragent_addr instead of conn->client_addr to obtain the
>> REMOTE_HOST.
>>
>> what about "Require ip ..."?
>>
>
> I agree that require host should track to the same entity as the require
> ip,
> which means the behavior right now is incorrect.
>
> There could be a Require conn-ip / conn-host that looks "around" the
> request
> based user agent down to the connection level user agent (proxy) address.
>
> But this mismatch is unnecessarily confusing, and what the original
> remoteip
> module was meant to avoid.
>

This is already tracked as
https://bz.apache.org/bugzilla/show_bug.cgi?id=55348
- another side effect of the same issue.

Replace feather

2016-02-11 Thread Jim Jagielski

I was wondering about whether we should update the feather[1] with the new 
one...
I can do it...

1. https://httpd.apache.org/images/httpd_logo_wide_new.png
--
Sent via Pony Mail for dev@httpd.apache.org. 
View this email online at:
https://pony-poc.apache.org/list.html?dev@httpd.apache.org

Re: balancer-manager docs

2016-02-11 Thread Jim Jagielski

A rough and very brief framework of such a guide is now available...

http://httpd.apache.org/docs/trunk/howto/reverse_proxy.html

On 2016-02-10 06:21, Luca Toscano  wrote: 
> 2016-02-10 10:33 GMT+01:00 Stefan Eissing :
> 
> > If you write one, I write one for http2! :-)
> >
> >
> +1+1+1+1 :)
> 
--
Sent via Pony Mail for dev@httpd.apache.org. 
View this email online at:
https://pony-poc.apache.org/list.html?dev@httpd.apache.org

Re: httpd-trunk/modules/http2 gets a proxy

Re: svn commit: r1729208 - in /httpd/httpd/trunk/modules: proxy/proxy_util.c ssl/ssl_engine_io.c

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

FYI: Backport of mod_proxy_hcheck

Re: Replace feather

Re: collaboration request - apache server automation testing with swat tool

Re: ABI report

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

Re: mod_proxy_http2

Re: svn commit: r1729826 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c

Re: mod_proxy_http2

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

Re: Shouldn't ap_get_remote_host use req->useragent_addr?

Re: FYI: Backport of mod_proxy_hcheck

Re: FYI: Backport of mod_proxy_hcheck

Re: FYI: Backport of mod_proxy_hcheck

Re: svn commit: r1729901 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

Re: svn commit: r1729901 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

Re: Support for OpenSSL 1.1.0

Re: svn commit: r1729901 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

Re: svn commit: r1729876 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h server/core.c

Re: svn commit: r1729876 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h server/core.c

Re: httpd-trunk/modules/http2 gets a proxy

Re: Shouldn't ap_get_remote_host use req->useragent_addr?

Replace feather

Re: balancer-manager docs

29 matches

Site Navigation

Mail list logo

Footer information