Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c

[Jacob Champion]

On 11/16/2016 04:32 AM, Ruediger Pluem wrote:

(but what has precedence in this case host or request)


The "effective request URI", as defined by Section 5.5, seems to be 
pretty clear that if the request-target is absolute, the Host header is 
irrelevant:


   If the request-target is in absolute-form, the effective request URI
   is the same as the request-target.

Then it's just up to the server admin, I think, whether to be strict 
(4xx) or lenient (replace Host with the request-target authority) for 
non-compliant requests that mismatch the two.


I seem to remember an IETF conversation about this, but I'm having 
trouble finding it now. (The one about proxies keeps coming up, but 
that's not what I'm remembering...)


--Jacob

Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c

[Jacob Champion]

On 11/16/2016 05:01 AM, William A Rowe Jr wrote:

We need to tolerate their presence. But we should ignore the guidance that
sf originally quoted, that the URI host supersedes the Host header, it does
not, they are two different entities it the proxy case


The "different entities" interpretation made sense to me too, but after 
re-reading the spec and seeing what the browsers actually do, I'm not so 
sure. (I'm a relative noob when it comes to the proxy sides of the spec, 
so corrections are appreciated.)


From section 5.4:

   A client MUST send a Host header field in all HTTP/1.1 request
   messages.  If the target URI includes an authority component, then a
   client MUST send a field-value for Host that is identical to that
   authority component, excluding any userinfo subcomponent and its "@"
   delimiter (Section 2.7.1).  If the authority component is missing or
   undefined for the target URI, then a client MUST send a Host header
   field with an empty field-value.

That's pretty absolute, and there doesn't seem to be an exception carved 
out for proxies. And in practice, after giving Chromium and Firefox a 
try with a local netcat "proxy", the Host headers they send are indeed 
derived from the target URI, *not* the hostname of the HTTP proxy. I'd 
like to see what other browsers do as well.


This would appear to prevent name-based hosting of multiple proxies and 
origin servers at the same IP address, which seems strange to me, given 
that the Host header would be an appropriate resolution tool in that 
case... so I'm hoping there's something I'm missing.


Maybe no one needs to do that? Does anyone have experience with a 
client/user-agent that makes use of name-based virtual proxies?


--Jacob

Re: apreq release

[Steve Hay]

On 15 November 2016 at 09:26, Issac Goldstand  wrote:
> Hi all,
>
> Someone (finally) noticed that apreq's test suite isn't compatible with
> Apache 2.4 and requested a change.  Given that we haven't released an
> updated apreq in nearly 6 years, I'm inclined to make/test the changes
> to the test suite and immediately go to a release cycle.
>
> Does anyone want time to add anything else to libapreq-2.14 before I
> start tarring and voting (in the next few days, I hope)?
>

All looks good here on Win32 - the current SVN version passes all
tests using VC++ 2010, perl-5.25.3, mod_perl-2.0.10 and either
httpd-2.2.31 or httpd-2.4.23. (Whatever the httpd-2.4 incompatibility
was seems not to affect anything on Win32!)

Re: apreq release

[Brian J. France]

This is just merging the perl stuff into mod_perl, right?

Not merging mod_apreq2 and all the request cache/re-play bucket, POST reading, 
file uploading, etc stuff, right?

I really don't want to have to include mod_perl so my C modules can read POST 
data and handle file uploads.

Cheers,

Brian


> On Nov 16, 2016, at 4:42 AM, Issac Goldstand  wrote:
> 
> Given that the C was (finally) merged into httpd years ago, and given
> that there are no proposed code changes, I'd say that's not such a bad
> idea...
> 
> I've become a bit rusty in Perl (and even with apreq) over the years,
> but IIRC, all of the Perl glue is in
> http://svn.apache.org/repos/asf/httpd/apreq/trunk/glue/perl/
> 
> I'll take a crack at seeing if I can fold it into mod_perl despite the rust.
> 
> 
> On 11/15/2016 2:45 PM, Andres Thomas Stivalet wrote:
>> Good news!! No idea why apreq hasn't just been merged into mod_perl
>> after all these years.
>> 
>> A+++
>> 
>> On Nov 15, 2016 3:27 AM, "Issac Goldstand" > > wrote:
>> 
>>Hi all,
>> 
>>Someone (finally) noticed that apreq's test suite isn't compatible with
>>Apache 2.4 and requested a change.  Given that we haven't released an
>>updated apreq in nearly 6 years, I'm inclined to make/test the changes
>>to the test suite and immediately go to a release cycle.
>> 
>>Does anyone want time to add anything else to libapreq-2.14 before I
>>start tarring and voting (in the next few days, I hope)?
>> 
>> 
>>-
>>To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
>>
>>For additional commands, e-mail: dev-h...@perl.apache.org
>>
>> 
> 

Re: apreq release

[Brian J. France]

This is just merging the perl stuff into mod_perl, right?

Not merging mod_apreq2 and all the request cache/re-play bucket, POST reading, 
file uploading, etc stuff, right?

I really don't want to have to include mod_perl so my C modules can read POST 
data and handle file uploads.

Cheers,

Brian


> On Nov 16, 2016, at 4:42 AM, Issac Goldstand  wrote:
> 
> Given that the C was (finally) merged into httpd years ago, and given
> that there are no proposed code changes, I'd say that's not such a bad
> idea...
> 
> I've become a bit rusty in Perl (and even with apreq) over the years,
> but IIRC, all of the Perl glue is in
> http://svn.apache.org/repos/asf/httpd/apreq/trunk/glue/perl/
> 
> I'll take a crack at seeing if I can fold it into mod_perl despite the rust.
> 
> 
> On 11/15/2016 2:45 PM, Andres Thomas Stivalet wrote:
>> Good news!! No idea why apreq hasn't just been merged into mod_perl
>> after all these years.
>> 
>> A+++
>> 
>> On Nov 15, 2016 3:27 AM, "Issac Goldstand" > > wrote:
>> 
>>Hi all,
>> 
>>Someone (finally) noticed that apreq's test suite isn't compatible with
>>Apache 2.4 and requested a change.  Given that we haven't released an
>>updated apreq in nearly 6 years, I'm inclined to make/test the changes
>>to the test suite and immediately go to a release cycle.
>> 
>>Does anyone want time to add anything else to libapreq-2.14 before I
>>start tarring and voting (in the next few days, I hope)?
>> 
>> 
>>-
>>To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
>>
>>For additional commands, e-mail: dev-h...@perl.apache.org
>>
>> 
> 

Re: svn commit: r1769965 - /httpd/httpd/trunk/server/vhost.c

[William A Rowe Jr]

On Wed, Nov 16, 2016 at 1:52 PM, Ruediger Pluem  wrote:

>
> On 11/16/2016 01:05 PM, wr...@apache.org wrote:
> > Author: wrowe
> > Date: Wed Nov 16 12:05:53 2016
> > New Revision: 1769965
> >
> > URL: http://svn.apache.org/viewvc?rev=1769965=rev
> > Log:
> > Actually cause the Host header to be overridden, as noted by rpluem,
> > and simplify now that there isn't a log-only mode.
> >
> > I believe this logic to be busted. Given this request;
> >
> > GET http://distant-host.com/ HTTP/1.1
> > Host: proxy-host
> >
> > we would now fail to evaluate the proxy-host virtual host rules.
> >
> > This seems like a breaking change to our config. mod_proxy already
> > follows this rule of RFC7230 section 5.4;
> >
> >When a proxy receives a request with an absolute-form of
> >request-target, the proxy MUST ignore the received Host header field
> >(if any) and instead replace it with the host information of the
> >request-target.  A proxy that forwards such a request MUST generate a
> >new Host field-value based on the received request-target rather than
> >forward the received Host field-value.
> >
> > Section 5.5 of RFC7230 has this to say;
> >
> >Once the effective request URI has been constructed, an origin server
> >needs to decide whether or not to provide service for that URI via
> >the connection in which the request was received.  For example, the
> >request might have been misdirected, deliberately or accidentally,
> >such that the information within a received request-target or Host
> >header field differs from the host or port upon which the connection
> >has been made.  If the connection is from a trusted gateway, that
> >inconsistency might be expected; otherwise, it might indicate an
> >attempt to bypass security filters, trick the server into delivering
> >non-public content, or poison a cache.  See Section 9 for security
> >considerations regarding message routing.
> >
> > Section 5.3.1 states;
> >
> >To allow for transition to the absolute-form for all requests in some
> >future version of HTTP, a server MUST accept the absolute-form in
> >requests, even though HTTP/1.1 clients will only send them in
> >requests to proxies.
> >
> > It seems to me we should simply trust the Host: header and dump this
> whole
> > mess. If we want to reject requests in absolute form after the proxy
> modules
> > have had a chance to accept them, that wouldn't be a bad solution.
> >
> > Modified:
> > httpd/httpd/trunk/server/vhost.c
> >
> > Modified: httpd/httpd/trunk/server/vhost.c
> > URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/
> vhost.c?rev=1769965=1769964=1769965=diff
> > 
> ==
> > --- httpd/httpd/trunk/server/vhost.c (original)
> > +++ httpd/httpd/trunk/server/vhost.c Wed Nov 16 12:05:53 2016
> > @@ -1165,13 +1165,11 @@ AP_DECLARE(void) ap_update_vhost_from_he
> >   * request line.
> >   */
> >  if (have_hostname_from_url && host_header != NULL) {
> > -const char *info = "Would replace";
> > -const char *new = construct_host_header(r, is_v6literal);
> > -apr_table_set(r->headers_in, "Host", r->hostname);
>
> IMHO the old code was wrong because r->hostname misses the surrounding []
> in case of IPV6 literals,
> but otherwise I see no change in logic here: Host part of the request
> still takes precedence over Host header.
>

Ok, I misread your original post, I thought you were pointing out that
r->hostname
is the Host: header value.


> > -info = "Replacing";
> > +const char *repl = construct_host_header(r, is_v6literal);
> > +apr_table_set(r->headers_in, "Host", repl);
> >  ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02417)
> > -  "%s Host header '%s' with host from request
> uri: "
> > -  "'%s'", info, host_header, new);
> > +  "Replacing host header '%s' with host '%s'
> given "
> > +  "in the request uri", host_header, repl);
> >  }
> >  }
> >
> >
> >
> >
>
> Doesn't this need to get added to the large conformance backport proposal?


Added, or discarded entirely, let's resume on the other discussion thread.

Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c

[William A Rowe Jr]

On Wed, Nov 16, 2016 at 1:32 PM, Ruediger Pluem  wrote:

>
> On 11/16/2016 01:08 PM, William A Rowe Jr wrote:
> >
> > Here's why I think the whole logic is busted and the preserve
> r->hostname is
> > the right thing to do for the outer request (not a child/client request
> to any
> > backend host)...
> >
> > I believe this logic to be busted. Given this request;
> >
> > GET http://distant-host.com/ HTTP/1.1
> > Host: proxy-host
> >
> > we would now fail to evaluate the proxy-host virtual host rules.
> >
> > This seems like a breaking change to our config. mod_proxy already
> > follows this rule of RFC7230 section 5.4;
> >
> >When a proxy receives a request with an absolute-form of
> >request-target, the proxy MUST ignore the received Host header field
> >(if any) and instead replace it with the host information of the
> >request-target.  A proxy that forwards such a request MUST generate a
> >new Host field-value based on the received request-target rather than
> >forward the received Host field-value.
> >
> > Section 5.5 of RFC7230 has this to say;
> >
> >Once the effective request URI has been constructed, an origin server
> >needs to decide whether or not to provide service for that URI via
> >the connection in which the request was received.  For example, the
> >request might have been misdirected, deliberately or accidentally,
> >such that the information within a received request-target or Host
> >header field differs from the host or port upon which the connection
> >has been made.  If the connection is from a trusted gateway, that
> >inconsistency might be expected; otherwise, it might indicate an
> >attempt to bypass security filters, trick the server into delivering
> >non-public content, or poison a cache.  See Section 9 for security
> >considerations regarding message routing.
> >
> > Section 5.3.1 states;
> >
> >To allow for transition to the absolute-form for all requests in some
> >future version of HTTP, a server MUST accept the absolute-form in
> >requests, even though HTTP/1.1 clients will only send them in
> >requests to proxies.
> >
> > It seems to me we should simply trust the Host: header and dump this
> whole
> > mess. If we want to reject requests in absolute form after the proxy
> modules
> > have had a chance to accept them, that wouldn't be a bad solution.
>
>
> Hm. I am confused now. 5.3.1 seem to state that we need to accept them in
> any
> case, even for non proxy requests. For the proxy case 5.4 seems to be
> pretty clear
> what to todo: Forget about the Host header, take it from the request.
> For the other case we can IMHO decide what we want to do accept it (but
> what has
> precedence in this case host or request) or drop / error out. I guess both
> behaviours
> can make sense. The later one as a security check, the former one if we
> are on a backend
> system and have a trusted proxy / reverse proxy aka gateway in front of us.
>

We need to tolerate their presence. But we should ignore the guidance that
sf originally quoted, that the URI host supersedes the Host header, it does
not, they are two different entities it the proxy case, and in the non-proxy
local resource case, a mismatch makes no sense in the first place.

We could reject non-proxy requests in absolute form if they were to some
local resource, but I think that is punitive. I'm not aware of any server
that
would refuse a request for http://example.com/x.html ... Host:example.com

We could reject non-proxy requests in absolute form if the URI host did
not match the specified Host: value. I'd initially wished it would, since
these are logged as 404's and typically searches for open proxies. That
confuses every new user/admin. But what about a client which resolved
the uri as submitted but then generated the Host: after some dns fixup?

Or we could continue to discard the target host specified in the local
resource uri, as we do today.

Can we get more eyeballs on this? Before backporting anything, I'd like
to eliminate this specific test altogether from the backport, or at least
refine it to be something meaningful.

Re: svn commit: r1769965 - /httpd/httpd/trunk/server/vhost.c

[Ruediger Pluem]

On 11/16/2016 01:05 PM, wr...@apache.org wrote:
> Author: wrowe
> Date: Wed Nov 16 12:05:53 2016
> New Revision: 1769965
> 
> URL: http://svn.apache.org/viewvc?rev=1769965=rev
> Log:
> Actually cause the Host header to be overridden, as noted by rpluem,
> and simplify now that there isn't a log-only mode.
> 
> I believe this logic to be busted. Given this request;
> 
> GET http://distant-host.com/ HTTP/1.1
> Host: proxy-host
> 
> we would now fail to evaluate the proxy-host virtual host rules.
> 
> This seems like a breaking change to our config. mod_proxy already
> follows this rule of RFC7230 section 5.4;
> 
>When a proxy receives a request with an absolute-form of
>request-target, the proxy MUST ignore the received Host header field
>(if any) and instead replace it with the host information of the
>request-target.  A proxy that forwards such a request MUST generate a
>new Host field-value based on the received request-target rather than
>forward the received Host field-value.
> 
> Section 5.5 of RFC7230 has this to say;
> 
>Once the effective request URI has been constructed, an origin server
>needs to decide whether or not to provide service for that URI via
>the connection in which the request was received.  For example, the
>request might have been misdirected, deliberately or accidentally,
>such that the information within a received request-target or Host
>header field differs from the host or port upon which the connection
>has been made.  If the connection is from a trusted gateway, that
>inconsistency might be expected; otherwise, it might indicate an
>attempt to bypass security filters, trick the server into delivering
>non-public content, or poison a cache.  See Section 9 for security
>considerations regarding message routing.
> 
> Section 5.3.1 states;
> 
>To allow for transition to the absolute-form for all requests in some
>future version of HTTP, a server MUST accept the absolute-form in
>requests, even though HTTP/1.1 clients will only send them in
>requests to proxies.
> 
> It seems to me we should simply trust the Host: header and dump this whole
> mess. If we want to reject requests in absolute form after the proxy modules
> have had a chance to accept them, that wouldn't be a bad solution.
> 
> 
> 
> Modified:
> httpd/httpd/trunk/server/vhost.c
> 
> Modified: httpd/httpd/trunk/server/vhost.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/vhost.c?rev=1769965=1769964=1769965=diff
> ==
> --- httpd/httpd/trunk/server/vhost.c (original)
> +++ httpd/httpd/trunk/server/vhost.c Wed Nov 16 12:05:53 2016
> @@ -1165,13 +1165,11 @@ AP_DECLARE(void) ap_update_vhost_from_he
>   * request line.
>   */
>  if (have_hostname_from_url && host_header != NULL) {
> -const char *info = "Would replace";
> -const char *new = construct_host_header(r, is_v6literal);
> -apr_table_set(r->headers_in, "Host", r->hostname);

IMHO the old code was wrong because r->hostname misses the surrounding [] in 
case of IPV6 literals,
but otherwise I see no change in logic here: Host part of the request still 
takes precedence over Host header.

> -info = "Replacing";
> +const char *repl = construct_host_header(r, is_v6literal);
> +apr_table_set(r->headers_in, "Host", repl);
>  ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02417)
> -  "%s Host header '%s' with host from request uri: "
> -  "'%s'", info, host_header, new);
> +  "Replacing host header '%s' with host '%s' given "
> +  "in the request uri", host_header, repl);
>  }
>  }
>  
> 
> 
> 

Doesn't this need to get added to the large conformance backport proposal?

Regards

Rüdiger

Better ./configure --help wording for paths?

[William A Rowe Jr]

Can we agree on a keyword/wording convention here for httpd-2.5-dev?

  --with-apr=PATH prefix for installed APR or the full path to
  --with-pcre=PATHUse external PCRE library
  --with-valgrind[=DIR]   Enable code to reduce valgrind false positives
  (optionally: set path to valgrind headers)
  --with-distcache=PATH   Distcache installation directory
  --with-z=PATH   use a specific zlib library
  --with-libxml2=DIR  Specify location of libxml2
  --with-brotli=PATH  Brotli installation directory
  --with-lua=PATH Path to the Lua 5.2/5.1 prefix
  --with-serf=PATHSerf client library
  --with-ssl=PATH OpenSSL installation directory
  --with-nghttp2=PATH nghttp2 installation directory
  directory.

Contrast to apr-2.0 and the autoconf keywords and text;

Installation directories:
  --prefix=PREFIX install architecture-independent files in PREFIX
  [/usr/local/apr]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
  [PREFIX]

By default, `make install' will install all the files in
`/usr/local/apr/bin', `/usr/local/apr/lib' etc.  You can specify
an installation prefix other than `/usr/local/apr' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIRuser executables [EPREFIX/bin]
  --sbindir=DIR   system admin executables [EPREFIX/sbin]
  --libexecdir=DIRprogram executables [EPREFIX/libexec]
  --sysconfdir=DIRread-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIRmodifiable architecture-independent data
[PREFIX/com]
  --localstatedir=DIR modifiable single-machine data [PREFIX/var]
  --libdir=DIRobject code libraries [EPREFIX/lib]
  --includedir=DIRC header files [PREFIX/include]
  --oldincludedir=DIR C header files for non-gcc [/usr/include]
  --datarootdir=DIR   read-only arch.-independent data root
[PREFIX/share]
  --datadir=DIR   read-only architecture-independent data
[DATAROOTDIR]
  --infodir=DIR   info documentation [DATAROOTDIR/info]
  --localedir=DIR locale-dependent data [DATAROOTDIR/locale]
  --mandir=DIRman documentation [DATAROOTDIR/man]
  --docdir=DIRdocumentation root [DATAROOTDIR/doc/PACKAGE]
  --htmldir=DIR   html documentation [DOCDIR]
  --dvidir=DIRdvi documentation [DOCDIR]
  --pdfdir=DIRpdf documentation [DOCDIR]
  --psdir=DIR ps documentation [DOCDIR]
  --with-sysroot=DIR Search for dependent libraries within DIR
  --with-installbuilddir=DIR location to store APR build files (defaults to
'${datadir}/build')
  --with-efence[=DIR] path to Electric Fence installation
  --with-valgrind[=DIR]   Enable code to teach valgrind about apr pools
  (optionally: set path to valgrind headers)
  --with-egd[=DIR]use EGD-compatible socket
  --with-openssl=DIR  specify location of OpenSSL
  --with-nss=DIR  specify location of NSS
  --with-commoncrypto=DIR specify location of CommonCrypto
  --with-gdbm=DIR enable GDBM support
  --with-ndbm=PATHFind the NDBM header and library in `PATH/include'
  and `PATH/lib'. If PATH is of the form
`HEADER:LIB',
  library in LIB. If you omit the `=PATH' part
  --with-berkeley-db=PATH Find the Berkeley DB header and library in
  `PATH/include' and `PATH/lib'. If PATH is of the
  `=PATH' part completely, the configure script will
  --with-pgsql=DIRspecify PostgreSQL location
  --with-mysql=DIRenable MySQL DBD driver
  --with-sqlite3=DIR  enable sqlite3 DBD driver
  --with-sqlite2=DIR  enable sqlite2 DBD driver
  --with-oracle-include=DIR
  path to Oracle include files
  --with-oracle=DIR   enable Oracle DBD driver; giving ORACLE_HOME as
DIR
  --with-odbc=DIR specify ODBC location
  --with-libxml2=DIR  specify libxml2 location
  --with-expat=DIRspecify Expat location
  --with-iconv=DIRpath to iconv installation

Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c

[Ruediger Pluem]

On 11/16/2016 01:08 PM, William A Rowe Jr wrote:
> On Tue, Nov 8, 2016 at 1:39 PM, Ruediger Pluem  > wrote:
> 
> 
> On 11/04/2016 03:20 PM, wr...@apache.org  wrote:
> > Author: wrowe
> > Date: Fri Nov  4 14:20:16 2016
> > New Revision: 1768036
> >
> > URL: http://svn.apache.org/viewvc?rev=1768036=rev 
> 
> > Log:
> > Add an option to enforce stricter HTTP conformance
> >
> > This is a first stab, the checks will likely have to be revised.
> > For now, we check
> >
> >  * if the request line contains control characters
> >  * if the request uri has fragment or username/password
> >  * that the request method is standard or registered with 
> RegisterHttpMethod
> >  * that the request protocol is of the form HTTP/[1-9]+.[0-9]+,
> >or missing for 0.9
> >  * if there is garbage in the request line after the protocol
> >  * if any request header contains control characters
> >  * if any request header has an empty name
> >  * for the host name in the URL or Host header:
> >- if an IPv4 dotted decimal address: Reject octal or hex values, 
> require
> >  exactly four parts
> >- if a DNS host name: Reject non-alphanumeric characters besides '.' 
> and
> >  '-'. As a side effect, this rejects multiple Host headers.
> >  * if any response header contains control characters
> >  * if any response header has an empty name
> >  * that the Location response header (if present) has a valid scheme 
> and is
> >absolute
> >
> > If we have a host name both from the URL and the Host header, we 
> replace the
> > Host header with the value from the URL to enforce RFC conformance.
> >
> > There is a log-only mode, but the loglevels of the logged messages need 
> some
> > thought/work. Currently, the  checks for incoming data log for 'core' 
> and the
> > checks for outgoing data log for 'http'. Maybe we need a way to 
> configure the
> > loglevels separately from the core/http loglevels.
> >
> > change protocol number parsing in strict mode according to HTTPbis draft
> > - only accept single digit version components
> > - don't accept white-space after protocol specification
> >
> > Clean up comment, fix log tags.
> > Submitted by: sf
> > Backports: r1426877, r1426879, r1426988, r1426992
> > Modified: httpd/httpd/branches/2.4.x-merge-http-strict/server/vhost.c
> > URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x-merge-http-strict/server/vhost.c?rev=1768036=1768035=1768036=diff
> 
> 
> > 
> ==
> > --- httpd/httpd/branches/2.4.x-merge-http-strict/server/vhost.c 
> (original)
> > +++ httpd/httpd/branches/2.4.x-merge-http-strict/server/vhost.c Fri Nov 
>  4 14:20:16 2016
> > +if (conf->http_conformance & AP_HTTP_CONFORMANCE_STRICT) {
> > +/*
> > + * If we have both hostname from an absoluteURI and a Host 
> header,
> > + * we must ignore the Host header (RFC 2616 5.2).
> > + * To enforce this, we reset the Host header to the value from 
> the
> > + * request line.
> > + */
> > +if (have_hostname_from_url && host_header != NULL) {
> > +const char *info = "Would replace";
> > +const char *new = construct_host_header(r, is_v6literal);
> > +if (!(conf->http_conformance & 
> AP_HTTP_CONFORMANCE_LOGONLY)) {
> > +apr_table_set(r->headers_in, "Host", r->hostname);
> 
> Hm, why don't we use "new" here instead of r->hostname
> 
> > +info = "Replacing";
> > +}
> > +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02417)
> > +  "%s Host header '%s' with host from request 
> uri: "
> > +  "'%s'", info, host_header, new);
> > +}
> > +}
> 
>  
> Good question, with LOGONLY no longer an option, all that logic got simpler.
> 
> Here's why I think the whole logic is busted and the preserve r->hostname is
> the right thing to do for the outer request (not a child/client request to any
> backend host)...
> 
> I believe this logic to be busted. Given this request;
> 
> GET http://distant-host.com/ HTTP/1.1
> Host: proxy-host
> 
> we would now fail to evaluate the proxy-host virtual host rules.
> 
> This seems like a breaking change to our config. mod_proxy already
> follows this rule of RFC7230 section 5.4;
> 
>When a proxy receives a request with an absolute-form of
>request-target, the proxy MUST 

Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c

[William A Rowe Jr]

On Tue, Nov 8, 2016 at 1:39 PM, Ruediger Pluem  wrote:

>
> On 11/04/2016 03:20 PM, wr...@apache.org wrote:
> > Author: wrowe
> > Date: Fri Nov  4 14:20:16 2016
> > New Revision: 1768036
> >
> > URL: http://svn.apache.org/viewvc?rev=1768036=rev
> > Log:
> > Add an option to enforce stricter HTTP conformance
> >
> > This is a first stab, the checks will likely have to be revised.
> > For now, we check
> >
> >  * if the request line contains control characters
> >  * if the request uri has fragment or username/password
> >  * that the request method is standard or registered with
> RegisterHttpMethod
> >  * that the request protocol is of the form HTTP/[1-9]+.[0-9]+,
> >or missing for 0.9
> >  * if there is garbage in the request line after the protocol
> >  * if any request header contains control characters
> >  * if any request header has an empty name
> >  * for the host name in the URL or Host header:
> >- if an IPv4 dotted decimal address: Reject octal or hex values,
> require
> >  exactly four parts
> >- if a DNS host name: Reject non-alphanumeric characters besides '.'
> and
> >  '-'. As a side effect, this rejects multiple Host headers.
> >  * if any response header contains control characters
> >  * if any response header has an empty name
> >  * that the Location response header (if present) has a valid scheme and
> is
> >absolute
> >
> > If we have a host name both from the URL and the Host header, we replace
> the
> > Host header with the value from the URL to enforce RFC conformance.
> >
> > There is a log-only mode, but the loglevels of the logged messages need
> some
> > thought/work. Currently, the  checks for incoming data log for 'core'
> and the
> > checks for outgoing data log for 'http'. Maybe we need a way to
> configure the
> > loglevels separately from the core/http loglevels.
> >
> > change protocol number parsing in strict mode according to HTTPbis draft
> > - only accept single digit version components
> > - don't accept white-space after protocol specification
> >
> > Clean up comment, fix log tags.
> > Submitted by: sf
> > Backports: r1426877, r1426879, r1426988, r1426992
> > Modified: httpd/httpd/branches/2.4.x-merge-http-strict/server/vhost.c
> > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x-
> merge-http-strict/server/vhost.c?rev=1768036=
> 1768035=1768036=diff
> > 
> ==
> > --- httpd/httpd/branches/2.4.x-merge-http-strict/server/vhost.c
> (original)
> > +++ httpd/httpd/branches/2.4.x-merge-http-strict/server/vhost.c Fri
> Nov  4 14:20:16 2016
> > +if (conf->http_conformance & AP_HTTP_CONFORMANCE_STRICT) {
> > +/*
> > + * If we have both hostname from an absoluteURI and a Host
> header,
> > + * we must ignore the Host header (RFC 2616 5.2).
> > + * To enforce this, we reset the Host header to the value from
> the
> > + * request line.
> > + */
> > +if (have_hostname_from_url && host_header != NULL) {
> > +const char *info = "Would replace";
> > +const char *new = construct_host_header(r, is_v6literal);
> > +if (!(conf->http_conformance &
> AP_HTTP_CONFORMANCE_LOGONLY)) {
> > +apr_table_set(r->headers_in, "Host", r->hostname);
>
> Hm, why don't we use "new" here instead of r->hostname
>
> > +info = "Replacing";
> > +}
> > +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02417)
> > +  "%s Host header '%s' with host from request
> uri: "
> > +  "'%s'", info, host_header, new);
> > +}
> > +}


Good question, with LOGONLY no longer an option, all that logic got simpler.

Here's why I think the whole logic is busted and the preserve r->hostname is
the right thing to do for the outer request (not a child/client request to
any
backend host)...

I believe this logic to be busted. Given this request;

GET http://distant-host.com/ HTTP/1.1
Host: proxy-host

we would now fail to evaluate the proxy-host virtual host rules.

This seems like a breaking change to our config. mod_proxy already
follows this rule of RFC7230 section 5.4;

   When a proxy receives a request with an absolute-form of
   request-target, the proxy MUST ignore the received Host header field
   (if any) and instead replace it with the host information of the
   request-target.  A proxy that forwards such a request MUST generate a
   new Host field-value based on the received request-target rather than
   forward the received Host field-value.

Section 5.5 of RFC7230 has this to say;

   Once the effective request URI has been constructed, an origin server
   needs to decide whether or not to provide service for that URI via
   the connection in which the request was received.  For example, the
   request might have been misdirected, deliberately or accidentally,
   such 

Re: apreq release

[Issac Goldstand]

Given that the C was (finally) merged into httpd years ago, and given
that there are no proposed code changes, I'd say that's not such a bad
idea...

I've become a bit rusty in Perl (and even with apreq) over the years,
but IIRC, all of the Perl glue is in
http://svn.apache.org/repos/asf/httpd/apreq/trunk/glue/perl/

I'll take a crack at seeing if I can fold it into mod_perl despite the rust.


On 11/15/2016 2:45 PM, Andres Thomas Stivalet wrote:
> Good news!! No idea why apreq hasn't just been merged into mod_perl
> after all these years.
> 
> A+++
> 
> On Nov 15, 2016 3:27 AM, "Issac Goldstand"  > wrote:
> 
> Hi all,
> 
> Someone (finally) noticed that apreq's test suite isn't compatible with
> Apache 2.4 and requested a change.  Given that we haven't released an
> updated apreq in nearly 6 years, I'm inclined to make/test the changes
> to the test suite and immediately go to a release cycle.
> 
> Does anyone want time to add anything else to libapreq-2.14 before I
> start tarring and voting (in the next few days, I hope)?
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
> 
> For additional commands, e-mail: dev-h...@perl.apache.org
> 
> 

Re: apreq release

[Issac Goldstand]

Honestly, I've no clue.  The plan is just to add a few checks with
mod_version (if available) to deal with the 2.2/2.4 config syntax
changes, and the changes so far seem to only be in the test suite.  I
haven't hit any changes in libapreq itself yet.

I don't have any connection with the Debian maintainers, but if someone
on these lists does and has interest, they're welcome to update
following the ANNOUNCE message post-release.

On 11/15/2016 9:17 PM, Mark Hedges wrote:
> Any chance this is what keeps me from running the Apache::Test tests for
> Apache2::Controller under Apache 2.4?
> 
> Will this be packaged and released to Debian Stretch before it goes
> stable, or can you advise the package maintainers to update?
> 
> Thanks.
> Mark
> 
> On Tue, Nov 15, 2016 at 1:26 AM, Issac Goldstand  > wrote:
> 
> Hi all,
> 
> Someone (finally) noticed that apreq's test suite isn't compatible with
> Apache 2.4 and requested a change.  Given that we haven't released an
> updated apreq in nearly 6 years, I'm inclined to make/test the changes
> to the test suite and immediately go to a release cycle.
> 
> Does anyone want time to add anything else to libapreq-2.14 before I
> start tarring and voting (in the next few days, I hope)?
> 
> 

Re: apreq release

[Issac Goldstand]

Honestly, I've no clue.  The plan is just to add a few checks with
mod_version (if available) to deal with the 2.2/2.4 config syntax
changes, and the changes so far seem to only be in the test suite.  I
haven't hit any changes in libapreq itself yet.

I don't have any connection with the Debian maintainers, but if someone
on these lists does and has interest, they're welcome to update
following the ANNOUNCE message post-release.

On 11/15/2016 9:17 PM, Mark Hedges wrote:
> Any chance this is what keeps me from running the Apache::Test tests for
> Apache2::Controller under Apache 2.4?
> 
> Will this be packaged and released to Debian Stretch before it goes
> stable, or can you advise the package maintainers to update?
> 
> Thanks.
> Mark
> 
> On Tue, Nov 15, 2016 at 1:26 AM, Issac Goldstand  > wrote:
> 
> Hi all,
> 
> Someone (finally) noticed that apreq's test suite isn't compatible with
> Apache 2.4 and requested a change.  Given that we haven't released an
> updated apreq in nearly 6 years, I'm inclined to make/test the changes
> to the test suite and immediately go to a release cycle.
> 
> Does anyone want time to add anything else to libapreq-2.14 before I
> start tarring and voting (in the next few days, I hope)?
> 
> 

Re: svn commit: r1769900 - /httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en

[Luca Toscano]

Hi!

You are completely right, I forgot to put it in my commit message. The
"Compatibility" section of
https://httpd.apache.org/docs/trunk/mod/mod_headers.html#header is already
mentioning the >= 2.4.7 note so I thought to remove the duplicate.

If you feel that it would be better to restore it, I'll do it :)

Thanks!

Luca

2016-11-16 7:01 GMT+01:00 Marion & Christophe JAILLET <
christophe.jail...@wanadoo.fr>:

> Hi,
>
> why removing compatibility note (i.e. 2.4.7) ?
>
> CJ
>
>
>
> Le 15/11/2016 à 23:57, elu...@apache.org a écrit :
>
>> Author: elukey
>> Date: Tue Nov 15 22:57:36 2016
>> New Revision: 1769900
>>
>> URL: http://svn.apache.org/viewvc?rev=1769900=rev
>> Log:
>> documentation rebuild
>>
>> Modified:
>>  httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en
>>
>> Modified: httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en
>> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/m
>> od/mod_headers.html.en?rev=1769900=1769899=1769900=diff
>> 
>> ==
>> --- httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en (original)
>> +++ httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en Tue Nov 15
>> 22:57:36 2016
>> @@ -309,8 +309,16 @@ available in 2.4.10 and later
>> setifempty
>>   The request header is set, but only if there is no previous
>> header
>> -with this name.
>> -Available in 2.4.7 and later.
>> +with this name.
>> +
>> +The Content-Type header is a special use case since there might be
>> +the chance that its value have been determined but the header is not
>> part
>> +of the response when setifempty is evaluated.
>> +It is safer to use set for this use case like in the
>> +following example:
>> +Header set Content-Type
>> "text/plain" "expr=-z %{CONTENT_TYPE}"
>> +
>> +
>> unset
>>   The response header of this name is removed, if it exists.
>>
>>
>>
>>
>