Re: Listen 443 https (SSLEngine Optional - dual host)

[Reindl Harald]

Am 17.09.2017 um 03:07 schrieb Nick Edwards:

phpmyadmin 4.4.15  is YEARS old


and how does that change the fact that 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519#c1 "SERVER_PORT 80" 
in case of a https-connection is plain wrong?



we using 4.7 for nearly a year, 4.7.2 is current


nice for you when you don't have to support older PHP (sync the package 
to a RHEL 7 host with PHP 5.4 - my whole own software is PHP 7.1 only 
with strict-types but that's not related to the topic at all)


this from a troll who verbally abuses the hell out of people on other 
lists for posting similar comments using very outdated softwares   HAH, 
this ones in google for life.


the only troll in this thread is you and nobody asked you, just because 
i have never seen anything useful on any list since you only post if you 
face something from me and otherwise you are a silent lurker everywhere!


On Sun, Sep 17, 2017 at 10:24 AM, Reindl Harald > wrote:



that's even more worse - phpMyAdmin 4.4.15.10 seems to handle
something wrong because $_SERVER['SERVER_PORT'] is wrong - and i had
myself some bad code using that var instead of $_SERVER['HTTPS']
which again leaded in a endless loop

in case of phpMyAdmin it redirects to https://hostname:80/path/
after enter username/password - the workaround below in the config
file seems to solve that for now, but all in all that leaves a very
bad taste

if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
{
  $cfg['ForceSSL'] = false;
}
else
{
  $cfg['ForceSSL'] = true;
}


Am 14.09.2017 um 18:16 schrieb Reindl Harald:

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:

Ok, as I read the code a bit more, there is a tangle of
things that can influence port/scheme selection. But what I
can see, the version in *trunk* should do the right thing *iff*

a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

    ServerName xxx.yyy
    SSLEngine *:443
     ...


should do the right thing here. Internal methods used to
generator Redirect Location headers, namely
ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and
als fill the Env Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome
starts to warn about every page with a form tag and no TLS

[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of
/etc/httpd/conf/sites_enabled/contentlounge.conf:
Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald
>:



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
    UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http://
protocol instead https// on port 443 here even tiggers
mod_security

even if it would mitigate that issue - having ports in
redirect urls easily leads to a lot of other problems
when proxy-servers are part of the game

[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head
--insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1

Am 14.09.2017 um 12:00 schrieb Reindl Harald
>:



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized

but with "SSLEngine On" and
"SSLCertificateFile" configured non-https no
longer would work


OK, figured it out

Re: Listen 443 https (SSLEngine Optional - dual host)

[Nick Edwards]

phpmyadmin 4.4.15  is YEARS old

we using 4.7 for nearly a year, 4.7.2 is current

this from a troll who verbally abuses the hell out of people on other lists
for posting similar comments using very outdated softwares   HAH, this ones
in google for life.


On Sun, Sep 17, 2017 at 10:24 AM, Reindl Harald 
wrote:

>
> that's even more worse - phpMyAdmin 4.4.15.10 seems to handle something
> wrong because $_SERVER['SERVER_PORT'] is wrong - and i had myself some bad
> code using that var instead of $_SERVER['HTTPS'] which again leaded in a
> endless loop
>
> in case of phpMyAdmin it redirects to https://hostname:80/path/ after
> enter username/password - the workaround below in the config file seems to
> solve that for now, but all in all that leaves a very bad taste
>
> if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
> {
>  $cfg['ForceSSL'] = false;
> }
> else
> {
>  $cfg['ForceSSL'] = true;
> }
>
>
> Am 14.09.2017 um 18:16 schrieb Reindl Harald:
>
>> Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
>>
>>> Ok, as I read the code a bit more, there is a tangle of things that can
>>> influence port/scheme selection. But what I can see, the version in *trunk*
>>> should do the right thing *iff*
>>>
>>> a) you use "SSLEngine *:443" instead of "Optional"
>>> b) you use "ServerName xxx.yyy" *without* a port name
>>>
>>> the a
>>> 
>>>ServerName xxx.yyy
>>>SSLEngine *:443
>>> ...
>>> 
>>>
>>> should do the right thing here. Internal methods used to generator
>>> Redirect Location headers, namely
>>> ap_construct_url()
>>> ap_get_server_port()
>>> ap_http_scheme()
>>> should give back the correct values for each connection and als fill the
>>> Env Variables with the correct values.
>>>
>>
>> what means "trunk" here?
>> a future 2.5/2.6/3.0 or a 2.4.x in the near future?
>>
>> within 2 weeks you need TLS on each and every host since Chrome starts to
>> warn about every page with a form tag and no TLS
>>
>> [root@srv-rhsoft:~]$ apachectl -t
>> AH00526: Syntax error on line 29 of /etc/httpd/conf/sites_enabled/
>> contentlounge.conf:
>> Argument must be On, Off, or Optional
>>
>>> Am 14.09.2017 um 15:46 schrieb Reindl Harald :



 Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

> Harald,
> could you check if a configuration like:
>UseCanonicalPhysicalPort on
> in the server or vhost mitigates the problem?
>

 it makes it even more terrible and the resulting http:// protocol
 instead https// on port 443 here even tiggers mod_security

 even if it would mitigate that issue - having ports in redirect urls
 easily leads to a lot of other problems when proxy-servers are part of the
 game

 [harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure
 https://contentlounge/cms
 HTTP/1.1 301 Moved Permanently
 Date: Thu, 14 Sep 2017 13:43:06 GMT
 X-DNS-Prefetch-Control: off
 X-Content-Type-Options: nosniff
 X-Response-Time: D=1561 us
 Location: http://contentlounge:443/cms/
 Cache-Control: max-age=0
 Expires: Thu, 14 Sep 2017 13:43:06 GMT
 Content-Type: text/html; charset=iso-8859-1

 Am 14.09.2017 um 12:00 schrieb Reindl Harald :
>>
>>
>>
>> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>
>>> If you want to experiment...
 
 is already recognized

>>> but with "SSLEngine On" and "SSLCertificateFile" configured
>>> non-https no longer would work
>>>
>>
>> OK, figured it out
>>
>> * you need the *first* vhost with "SSLEngine On"
>> * others can have "SSLEngine optional" and listen to 80 and 443
>>
>> but there is a bug: https://bz.apache.org/bugzilla
>> /show_bug.cgi?id=61519
>>
>> if the trailing slash is missing in the url the automatic redirect to
>> the full qualified folder-path points to http:// instead https://
>> and that does not happen within a vhost dedicated to :443 and "SSLEngine 
>> On"
>>
>> i was trapped in a endless loop because the php script making a
>> redirect to https:// had a bug and missed the traling / too
>>
>> 
>> DocumentRoot "/www/contentlounge"
>> ServerName contentlounge.rhsoft.net
>> SSLEngine optional
>> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
>> 
>>
>> [harry@srv-rhsoft:~]$ curl --head --insecure
>> https://contentlounge/cms
>> HTTP/1.1 301 Moved Permanently
>> Date: Thu, 14 Sep 2017 09:40:27 GMT
>> X-DNS-Prefetch-Control: off
>> X-Content-Type-Options: nosniff
>> X-Response-Time: D=1311 us
>> Location: http://contentlounge/cms/
>> Cache-Control: max-age=0
>> Expires: Thu, 14 Sep 2017 09:40:27 GMT
>> Content-Type: text/html; charset=iso-8859-1
>>
>

Re: Listen 443 https (SSLEngine Optional - dual host)

[Reindl Harald]

assumption confirmed - and my connection is for sure https:// because of 
the mod_rewrite and finally HSTS


https://bz.apache.org/bugzilla/show_bug.cgi?id=61519 updated too

phpinfo():
SERVER_PORT 80


 ServerName www.rhsoft.net
 SSLEngine Optional
 SSLUseStapling On
 SSLCertificateFile "certs/rhsoft-www.conf_rsa.pem"
 SSLCertificateFile "certs/rhsoft-www.conf_ecdsa.pem"
 
  RewriteEngine on
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
 
 
  Header always set "Strict-Transport-Security" "max-age=31536000"
 


Am 17.09.2017 um 02:24 schrieb Reindl Harald:


that's even more worse - phpMyAdmin 4.4.15.10 seems to handle something 
wrong because $_SERVER['SERVER_PORT'] is wrong - and i had myself some 
bad code using that var instead of $_SERVER['HTTPS'] which again leaded 
in a endless loop


in case of phpMyAdmin it redirects to https://hostname:80/path/ after 
enter username/password - the workaround below in the config file seems 
to solve that for now, but all in all that leaves a very bad taste


if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
{
  $cfg['ForceSSL'] = false;
}
else
{
  $cfg['ForceSSL'] = true;
}


Am 14.09.2017 um 18:16 schrieb Reindl Harald:

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
Ok, as I read the code a bit more, there is a tangle of things that 
can influence port/scheme selection. But what I can see, the version 
in *trunk* should do the right thing *iff*


a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

   ServerName xxx.yyy
   SSLEngine *:443
    ...


should do the right thing here. Internal methods used to generator 
Redirect Location headers, namely

ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill 
the Env Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome starts 
to warn about every page with a form tag and no TLS


[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of 
/etc/httpd/conf/sites_enabled/contentlounge.conf:

Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald :



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
   UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol 
instead https// on port 443 here even tiggers mod_security


even if it would mitigate that issue - having ports in redirect urls 
easily leads to a lot of other problems when proxy-servers are part 
of the game


[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1

Am 14.09.2017 um 12:00 schrieb Reindl Harald 
:




Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized
but with "SSLEngine On" and "SSLCertificateFile" configured 
non-https no longer would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519


if the trailing slash is missing in the url the automatic redirect 
to the full qualified folder-path points to http:// instead 
https:// and that does not happen within a vhost dedicated to :443 
and "SSLEngine On"


i was trapped in a endless loop because the php script making a 
redirect to https:// had a bug and missed the traling / too



DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https (SSLEngine Optional - dual host)

[Reindl Harald]

that's even more worse - phpMyAdmin 4.4.15.10 seems to handle something 
wrong because $_SERVER['SERVER_PORT'] is wrong - and i had myself some 
bad code using that var instead of $_SERVER['HTTPS'] which again leaded 
in a endless loop


in case of phpMyAdmin it redirects to https://hostname:80/path/ after 
enter username/password - the workaround below in the config file seems 
to solve that for now, but all in all that leaves a very bad taste


if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
{
 $cfg['ForceSSL'] = false;
}
else
{
 $cfg['ForceSSL'] = true;
}


Am 14.09.2017 um 18:16 schrieb Reindl Harald:

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
Ok, as I read the code a bit more, there is a tangle of things that 
can influence port/scheme selection. But what I can see, the version 
in *trunk* should do the right thing *iff*


a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

   ServerName xxx.yyy
   SSLEngine *:443
    ...


should do the right thing here. Internal methods used to generator 
Redirect Location headers, namely

ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill 
the Env Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome starts 
to warn about every page with a form tag and no TLS


[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of 
/etc/httpd/conf/sites_enabled/contentlounge.conf:

Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald :



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
   UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol 
instead https// on port 443 here even tiggers mod_security


even if it would mitigate that issue - having ports in redirect urls 
easily leads to a lot of other problems when proxy-servers are part 
of the game


[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1


Am 14.09.2017 um 12:00 schrieb Reindl Harald :



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized
but with "SSLEngine On" and "SSLCertificateFile" configured 
non-https no longer would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519


if the trailing slash is missing in the url the automatic redirect 
to the full qualified folder-path points to http:// instead 
https:// and that does not happen within a vhost dedicated to :443 
and "SSLEngine On"


i was trapped in a endless loop because the php script making a 
redirect to https:// had a bug and missed the traling / too



DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: svn commit: r1808541 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml.fr

[Yann Ylavic]

Hi Lucien,

On Sat, Sep 16, 2017 at 4:00 PM,   wrote:
> Author: lgentis
> Date: Sat Sep 16 14:00:43 2017
> New Revision: 1808541
>
> URL: http://svn.apache.org/viewvc?rev=1808541=rev
> Log:
> XML update.
>
> Modified:
> httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml.fr
>
> Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml.fr
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml.fr?rev=1808541=1808540=1808541=diff
> ==
> --- httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml.fr [utf-8] (original)
> +++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml.fr [utf-8] Sat Sep 
> 16 14:00:43 2017
[]
>
> +Dans l'exemple suivant, on force le module à traiter les paquets de
> +données en provenance de l'arrière-plan du FCGI dès leur réception, sans 
> les
> +faire transiter par un tampon.

Maybe "backend" here (and possibly in other .fr pages) could be
translated as "serveur final" or even "serveur orgine" instead of
"arrière-plan"?
That is "serveur FGCI final/origine" ("origin server" being the RFC
term) which reads better IMHO...

Regards,
Yann.

Re: svn commit: r1426877 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c server/util.c server/vhost.c

[Eric Covener]

On Sat, Sep 16, 2017 at 9:48 AM, Yann Ylavic  wrote:
> On Sat, Sep 16, 2017 at 3:37 AM, Eric Covener  wrote:
>> On Sat, Dec 29, 2012 at 8:23 PM,   wrote:
>>>
>>> +/*
>>> + * If strict mode ever becomes the default, this should be folded into
>>> + * fix_hostname_non_v6()
>>> + */
>>> +static apr_status_t strict_hostname_check(request_rec *r, char *host,
>>> +  int logonly)
>>> +{
>>> +char *ch;
>>> +int is_dotted_decimal = 1, leading_zeroes = 0, dots = 0;
>>> +
>>> +for (ch = host; *ch; ch++) {
>>> +if (!apr_isascii(*ch)) {
>>> +goto bad;
>>> +}
>>> +else if (apr_isalpha(*ch) || *ch == '-') {
>>> +is_dotted_decimal = 0;
>>> +}
>>> +else if (ch[0] == '.') {
>>> +dots++;
>>> +if (ch[1] == '0' && apr_isdigit(ch[2]))
>>> +leading_zeroes = 1;
>>> +}
>>> +else if (!apr_isdigit(*ch)) {
>>> +   /* also takes care of multiple Host headers by denying commas */
>>> +goto bad;
>>> +}
>>> +}
>>> +if (is_dotted_decimal) {
>>> +if (host[0] == '.' || (host[0] == '0' && apr_isdigit(host[1])))
>>> +leading_zeroes = 1;
>>> +if (leading_zeroes || dots != 3) {
>>> +/* RFC 3986 7.4 */
>>> +goto bad;
>>> +}
>>> +}
>>> +else {
>>> +/* The top-level domain must start with a letter (RFC 1123 2.1) */
>>> +while (ch > host && *ch != '.')
>>> +ch--;
>>> +if (ch[0] == '.' && ch[1] != '\0' && !apr_isalpha(ch[1]))
>>> +goto bad;
>>> +}
>>> +return APR_SUCCESS;
>>> +
>>> +bad:
>>> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO()
>>> +  "[strict] Invalid host name '%s'%s%.6s",
>>> +  host, *ch ? ", problem near: " : "", ch);
>>> +if (logonly)
>>> +return APR_SUCCESS;
>>> +return APR_EINVAL;
>>> +}
>>
>> (sorry for the necromancy of this very old commit)
>>
>> Re: the 1123 2.1 reference a dozen lines from the end of the function:
>> RFC 1123 2.1 seems to say the opposite. Just a bug or something over
>> my head?
>>
>>   2.1  Host Names and Numbers
>>
>>   The syntax of a legal Internet host name was specified in RFC-952
>>   [DNS:4].  One aspect of host name syntax is hereby changed: the
>>   restriction on the first character is relaxed to allow either a
>>   letter or a digit.  Host software MUST support this more liberal
>>   syntax.
>
> RFC 1123 2.1 seems to be about the first character of the host, while
> the code checks the first one of the TLD. Are there TLDs starting with
> a digit?

I see, thanks.  The basis in 1123 is a bit later in 2.1 but doesn't
really seem normative:

If a dotted-decimal number can be entered without such
   identifying delimiters, then a full syntactic check must be
   made, because a segment of a host domain name is now allowed
   to begin with a digit and could legally be entirely numeric
   (see Section 6.1.2.4).  However, a valid host name can never
   have the dotted-decimal form #.#.#.#, since at least the
   highest-level component label will be alphabetic.

The 6.1.2.4 reference is likely an error because that is about compression.

It seems like we'd reject "1foo" but accept "1foo.com", but i am not
sure if this warrants an exception or reconsidering the check.

(In the case that had me looking, a high TCP port was used as the
hostname AND port in the Host header so it is clearly someone elses
bug at the core)

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

Re: svn commit: r1426877 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c server/util.c server/vhost.c

[Yann Ylavic]

On Sat, Sep 16, 2017 at 3:37 AM, Eric Covener  wrote:
> On Sat, Dec 29, 2012 at 8:23 PM,   wrote:
>>
>> +/*
>> + * If strict mode ever becomes the default, this should be folded into
>> + * fix_hostname_non_v6()
>> + */
>> +static apr_status_t strict_hostname_check(request_rec *r, char *host,
>> +  int logonly)
>> +{
>> +char *ch;
>> +int is_dotted_decimal = 1, leading_zeroes = 0, dots = 0;
>> +
>> +for (ch = host; *ch; ch++) {
>> +if (!apr_isascii(*ch)) {
>> +goto bad;
>> +}
>> +else if (apr_isalpha(*ch) || *ch == '-') {
>> +is_dotted_decimal = 0;
>> +}
>> +else if (ch[0] == '.') {
>> +dots++;
>> +if (ch[1] == '0' && apr_isdigit(ch[2]))
>> +leading_zeroes = 1;
>> +}
>> +else if (!apr_isdigit(*ch)) {
>> +   /* also takes care of multiple Host headers by denying commas */
>> +goto bad;
>> +}
>> +}
>> +if (is_dotted_decimal) {
>> +if (host[0] == '.' || (host[0] == '0' && apr_isdigit(host[1])))
>> +leading_zeroes = 1;
>> +if (leading_zeroes || dots != 3) {
>> +/* RFC 3986 7.4 */
>> +goto bad;
>> +}
>> +}
>> +else {
>> +/* The top-level domain must start with a letter (RFC 1123 2.1) */
>> +while (ch > host && *ch != '.')
>> +ch--;
>> +if (ch[0] == '.' && ch[1] != '\0' && !apr_isalpha(ch[1]))
>> +goto bad;
>> +}
>> +return APR_SUCCESS;
>> +
>> +bad:
>> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO()
>> +  "[strict] Invalid host name '%s'%s%.6s",
>> +  host, *ch ? ", problem near: " : "", ch);
>> +if (logonly)
>> +return APR_SUCCESS;
>> +return APR_EINVAL;
>> +}
>
> (sorry for the necromancy of this very old commit)
>
> Re: the 1123 2.1 reference a dozen lines from the end of the function:
> RFC 1123 2.1 seems to say the opposite. Just a bug or something over
> my head?
>
>   2.1  Host Names and Numbers
>
>   The syntax of a legal Internet host name was specified in RFC-952
>   [DNS:4].  One aspect of host name syntax is hereby changed: the
>   restriction on the first character is relaxed to allow either a
>   letter or a digit.  Host software MUST support this more liberal
>   syntax.

RFC 1123 2.1 seems to be about the first character of the host, while
the code checks the first one of the TLD. Are there TLDs starting with
a digit?