Re: 2.4.3x regression w/SSL vhost configs

> Am 12.04.2018 um 11:23 schrieb Yann Ylavic : > > Hi Stefan, > > On Thu, Apr 12, 2018 at 11:09 AM, Stefan Eissing > wrote: >> >>> Am 11.04.2018 um 22:24 schrieb Yann Ylavic : >>> >>> On Wed, Apr 11, 2018 at 7:54 PM,

Re: 2.4.3x regression w/SSL vhost configs

On Wed, Apr 11, 2018 at 10:24:23PM +0200, Yann Ylavic wrote: > On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton wrote: > > Yes, exactly - and for affected configs the defining feature is the > > absence of SSL* in the second vhost. The non-SSL config still takes > > effect as

Re: 2.4.3x regression w/SSL vhost configs

> Am 11.04.2018 um 22:24 schrieb Yann Ylavic : > > On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton wrote: >> On Wed, Apr 11, 2018 at 01:37:22PM -0400, Eric Covener wrote: >>> On Wed, Apr 11, 2018 at 1:07 PM, Yann Ylavic wrote: On

Re: 2.4.3x regression w/SSL vhost configs

Hi Stefan, On Thu, Apr 12, 2018 at 11:09 AM, Stefan Eissing wrote: > >> Am 11.04.2018 um 22:24 schrieb Yann Ylavic : >> >> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton wrote: >>> >>> Is mod_md expected to work for vhosts

Re: URL's in error pages

On Thu, Apr 12, 2018 at 1:46 PM, Eric Covener wrote: > > Here are a few options to silencing these scans/reports: > [X] remove the URL's The URL is already in the address bar if any screenshot/report matters, IMHO.

t/ssl/proxy.t

Does that work for anyone against a trunk server right now? On my MacOS, I get: > curl -k http://localhost:8555/ 504 Proxy Error Proxy Error The gateway did not receive a timely response from the upstream server or application.

Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c

If only for trunk then I would say Yes, lets optimize these struct fields. > On Apr 11, 2018, at 3:14 PM, Eric Covener wrote: > >> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original) >> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018 >> @@

Re: 2.4.3x regression w/SSL vhost configs

> Am 12.04.2018 um 12:49 schrieb Yann Ylavic : > > On Thu, Apr 12, 2018 at 11:34 AM, Stefan Eissing > wrote: >> >> >>> Am 12.04.2018 um 11:23 schrieb Yann Ylavic : >>> >>> Hi Stefan, >>> >>> On Thu, Apr 12, 2018 at

Re: URL's in error pages

In order of pref I'd say: o base64 encode the URL's and surround with some text that says its only useful for the webserver administrator. o remove the URLs > On Apr 12, 2018, at 7:46 AM, Eric Covener wrote: > > Scanners at $dayjob (and reports on security@) frequently

Re: t/ssl/proxy.t

Forget it. It was the usual openssl linked vs. openssl in $PATH mixup... > Am 12.04.2018 um 12:17 schrieb Stefan Eissing : > > Does that work for anyone against a trunk server right now? > > On my MacOS, I get: > >> curl -k http://localhost:8555/ > > > 504 Proxy

Re: 2.4.3x regression w/SSL vhost configs

On Thu, Apr 12, 2018 at 11:34 AM, Stefan Eissing wrote: > > >> Am 12.04.2018 um 11:23 schrieb Yann Ylavic : >> >> Hi Stefan, >> >> On Thu, Apr 12, 2018 at 11:09 AM, Stefan Eissing >> wrote: >>> Am 11.04.2018

URL's in error pages

Scanners at $dayjob (and reports on security@) frequently report that built-in error documents suffer from non-xss HTML injection from the request URL. Here are a few options to silencing these scans/reports: [ ] remove the URL's [ ] truncate them [ ] put them in HTML comments [ ] use CSS to

Win Code Analyses Trunk some modules

I reported before warnings from 2.4.33, see http://apache-http-server.18135.x6.nabble.com/Build-warnings-2-4-33-Win32-td5042506.html For your info: We have run on Trunk ( revision 1828799) some modules the GUI code analyses: mod_cache_socache mod_ssl mod_proxy mod_md mod_remoteip

Re: URL's in error pages

> On 12 Apr 2018, at 12:46, Eric Covener wrote: > > Scanners at $dayjob (and reports on security@) frequently report that > built-in error documents suffer from non-xss HTML injection from the > request URL. Deja vu there. I’m sure we’ve fixed some such, and done a grep on

Re: URL's in error pages

Since the encoded form is not very useful for humans, I'd sooner remove the URL from the page. As you said, we have access_log. As hesitant as I am to suggest Yet Another Directive, I also agree that this change should be configurable and defaulted to 'Off' for 2.4... no preference on trunk. --

Re: SNI normalization?

Regarding this, I wrote the attached patch that adds a new method AP_DECLARE(apr_status_t) ap_normalize_hostname(conn_rec *c, const char **phostname); to http_vhost.h with some internal rewiring so that request_rec fix_hostname() and this method have a common base. sni_fixup_hostname.patch

Re: URL's in error pages

On 04/12/2018 02:08 PM, Yann Ylavic wrote: > On Thu, Apr 12, 2018 at 1:46 PM, Eric Covener wrote: >> >> Here are a few options to silencing these scans/reports: >> > [X] remove the URL's > > The URL is already in the address bar if any screenshot/report matters, IMHO. >

Re: unsubscribe

As any other Apache project, you can find the instructions about how to unsubscribe in http://httpd.apache.org/lists.html#http-dev Luca 2018-04-12 17:35 GMT+02:00 Ray Jender : > Please remove me from this mailing list! >

Weird formatting when quoting on bz

In my browser at least, quoting (in reply to) messages and added text do not mix well on our bugzilla (while emails on bugs@ looks good). A blank line is automagically added after the quote, but none before the next one, so it doesn't help putting replies in context in both bz and emails.. Any

Re: 2.4.3x regression w/SSL vhost configs

On 04/12/2018 09:28 AM, Joe Orton wrote: > On Wed, Apr 11, 2018 at 10:24:23PM +0200, Yann Ylavic wrote: >> On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton wrote: >>> Yes, exactly - and for affected configs the defining feature is the >>> absence of SSL* in the second vhost. The

Re: URL's in error pages

On Thu, Apr 12, 2018 at 8:33 AM, Daniel Ruggeri wrote: > Since the encoded form is not very useful for humans, I'd sooner remove the > URL from the page. As you said, we have access_log. As hesitant as I am to > suggest Yet Another Directive, I also agree that this change

Re: URL's in error pages

On Thu, Apr 12, 2018 at 11:18 PM, Eric Covener wrote: > On Thu, Apr 12, 2018 at 8:33 AM, Daniel Ruggeri wrote: >> Since the encoded form is not very useful for humans, I'd sooner remove the >> URL from the page. As you said, we have access_log. As

unsubscribe

Please remove me from this mailing list!