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 Nov 16, 2016 20:29, "Jacob Champion"  wrote:
>
> 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

Doh, that's right.

This is why we had such a horrid time with unwarranted TLS SNI host headers
vs Host: headers for proxy requests through httpd:. I will need to review
all three and compare them to the effect of this new patch.

In the interim I suggest we withdraw this comparison, and bring it back up
as a post 2.4.24 change. Thoughts?

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: 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: 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&view=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&r1=1768035&r2=1768036&view=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 pro

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&view=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&r1=
> 1768035&r2=1768036&view=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 that th

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/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&view=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&r1=1768035&r2=1768036&view=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

> @@ -1040,23 +1108,79 @@ static void check_serverpath(request_rec
>  }
>  }
>  
> +static APR_INLINE const char *construct_host_header(request_rec *r,
> +int is_v6literal)
> +{
> +struct iovec iov[5];
> +apr_size_t nvec = 0;
> +/*
> + * We cannot use ap_get_server_name/port here, because we must
> + * ignore UseCanonicalName/Port.
> + */
> +if (is_v6literal) {
> +iov[nvec].iov_base = "[";
> +iov[nvec].iov_len = 1;
> +nvec++;
> +}
> +iov[nvec].iov_base = (void *)r->hostname;
> +iov[nvec].iov_len = strlen(r->hostname);
> +nvec++;
> +if (is_v6literal) {
> +iov[nvec].iov_base = "]";
> +iov[nvec].iov_len = 1;
> +nvec++;
> +}
> +if (r->parsed_uri.port_str) {
> +iov[nvec].iov_base = ":";
> +iov[nvec].iov_len = 1;
> +nvec++;
> +iov[nvec].iov_base = r->parsed_uri.port_str;
> +iov[nvec].iov_len = strlen(r->parsed_uri.port_str);
> +nvec++;
> +}
> +return apr_pstrcatv(r->pool, iov, nvec, NULL);
> +}
>  
>  AP_DECLARE(void) ap_update_vhost_from_headers(request_rec *r)
>  {
> -const char *host_header;
> +core_server_config *conf = 
> ap_get_core_module_config(r->server->module_config);
> +const char *host_header = apr_table_get(r->headers_in, "Host");
> +int is_v6literal, have_hostname_from_url = 0;
>  
>  if (r->hostname) {
>  /*
>   * If there was a host part in the Request-URI, ignore the 'Host'
>   * header.
>   */
> -fix_hostname(r, NULL);
> +have_hostname_from_url = 1;
> +is_v6literal = fix_hostname(r, NULL, conf->http_conformance);
>  }
> -else if ((host_header = apr_table_get(r->headers_in, "Host")) != NULL ) {
> -fix_hostname(r, host_header);
> +else if (host_header != NULL) {
> +is_v6literal = fix_hostname(r, host_header, conf->http_conformance);
>  }
>  if (r->status != HTTP_OK)
>  return;
> +
> +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";
>

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 Fri, Nov 4, 2016 at 12:46 PM, Jacob Champion 
wrote:

> [spec discussion]
>
> On 11/04/2016 09:40 AM, William A Rowe Jr wrote:
>
>> On Fri, Nov 4, 2016 at 9:47 AM, Eric Covener > > wrote:
>>
>>> There is even an example with no scheme:
>>>
>>> Location: /People.html#tim
>>>
>>
>> Not valid as a request (fragment not allowed)
>>
>
> ...but what does that have to do with the Location header? This is a valid
> and useful Location header value. (Clients won't send the fragment during
> the redirect; they'll save it to use during later presentation of the
> resource.)


Yup, this is an interesting point/question. Location header value !=
Request line URI value.

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]

[spec discussion]

On 11/04/2016 09:40 AM, William A Rowe Jr wrote:

On Fri, Nov 4, 2016 at 9:47 AM, Eric Covener mailto:cove...@gmail.com>> wrote:

There is even an example with no scheme:

Location: /People.html#tim


Not valid as a request (fragment not allowed)


...but what does that have to do with the Location header? This is a 
valid and useful Location header value. (Clients won't send the fragment 
during the redirect; they'll save it to use during later presentation of 
the resource.)


--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

[William A Rowe Jr]

On Fri, Nov 4, 2016 at 11:40 AM, William A Rowe Jr 
wrote:

>
> Give me about 24 hours to complete all this work, end of day today
> is my most optimistic timetable. Then we can discuss the resulting
> delta as a single unit/backport vote.  Because of a huge number of
> intervening commits to the relevant source files, mixing modern code
> changes based on nearly-4-year-old work in trunk is something of
> a nightmare (as we observed just syncing 2.2 to the state of the
> fixes already in 2.4.) I'll be starting a 2.2.current -> 2.4.current branch
> next, so the combination of that plus this trunk branch should get us
> to a parsing/strict observation shortly.
>

(If you do spot something amiss, you can quickly check against /trunk/
to see if the defect has been addressed already, then it will likely be
caught in my exhaustive backport list.)

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 Fri, Nov 4, 2016 at 9:47 AM, Eric Covener  wrote:

> On Fri, Nov 4, 2016 at 10:20 AM,   wrote:
> >  * that the Location response header (if present) has a valid scheme and
> is
> >absolute
>
> Too strict?
>
> https://tools.ietf.org/html/rfc7231#section-7.1.2
>
>The "Location" header field is used in some responses to refer to a
>specific resource in relation to the response.  The type of
>relationship is defined by the combination of request method and
>status code semantics.
>
>  Location = URI-reference
>
>The field value consists of a single URI-reference.  When it has the
>form of a relative reference ([RFC3986], Section 4.2), the final
>value is computed by resolving it against the effective request URI
>([RFC3986], Section 5).
>
> There is even an example with no scheme:
>
>  Location: /People.html#tim
>

Not valid as a request (fragment not allowed)

Beyond this, you may want to pend questions since there is a *very*
long list of backports to get this fork in sync with httpd-2.x trunk.
Much of the initial code has been re-thought and will take me the
better part of the day to sequentially merge. For small groups of
simple patches without much issue, I'm collapsing them (with credits
and multiple rev no's) - especially where the 'next patch' undoes some
of the changes in the prior patch and momentary flaw can be ignored.

I still have some lingering questions, but this will get you the full
picture
of where the change came from when reviewing the overall delta between
2.4.now and 2.4.next.

Give me about 24 hours to complete all this work, end of day today
is my most optimistic timetable. Then we can discuss the resulting
delta as a single unit/backport vote.  Because of a huge number of
intervening commits to the relevant source files, mixing modern code
changes based on nearly-4-year-old work in trunk is something of
a nightmare (as we observed just syncing 2.2 to the state of the
fixes already in 2.4.) I'll be starting a 2.2.current -> 2.4.current branch
next, so the combination of that plus this trunk branch should get us
to a parsing/strict observation shortly.

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

[Nick Kew]

On Fri, 2016-11-04 at 10:47 -0400, Eric Covener wrote:

> Too strict?

Be conservative in what you send.  An Absolute URL
is never going to be the wrong thing to send.

> https://tools.ietf.org/html/rfc7231#section-7.1.2

Another change from the HTTP RFCs we learned, where
Location MUST be absolute.

Though in practice, there was a lot of confusion,
with the CGI spec - and hence serverside apps -
permitting the relative semantics.  Seems recent
HTTP came into line with CGI on this one.

-- 
Nick Kew

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

[Eric Covener]

On Fri, Nov 4, 2016 at 10:20 AM,   wrote:
>  * that the Location response header (if present) has a valid scheme and is
>absolute

Too strict?

https://tools.ietf.org/html/rfc7231#section-7.1.2

   The "Location" header field is used in some responses to refer to a
   specific resource in relation to the response.  The type of
   relationship is defined by the combination of request method and
   status code semantics.

 Location = URI-reference

   The field value consists of a single URI-reference.  When it has the
   form of a relative reference ([RFC3986], Section 4.2), the final
   value is computed by resolving it against the effective request URI
   ([RFC3986], Section 5).


There is even an example with no scheme:


 Location: /People.html#tim

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