[Bug 61519] New: "SSLEngine optional" and http:// redirects if traling slash in the url is missing

[b***@apache.org]

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

Bug ID: 61519
Summary: "SSLEngine optional" and http:// redirects if traling
slash in the url is missing
Product: Apache httpd-2
Version: 2.4.27
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Core
Assignee: ***@httpd.apache.org
Reporter: ***@thelounge.net
Target Milestone: ---

* /cms/ is a physical folder
* user missed the trailing /
* while the request was https:// the rdirect goes to http://
* in case a script has a check and redirects non-https to https -> endless-loop

<VirtualHost *:80 *:443>
DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"
</VirtualHost>

[***@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

[b***@apache.org]

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

--- Comment #1 from Reindl Harald <***@thelounge.net> ---
my connection is for sure https:// because of the mod_rewrite and finally HSTS

phpinfo():
SERVER_PORT 80

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

[b***@apache.org]

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

Reindl Harald <***@thelounge.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |critical

[b***@apache.org]

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

--- Comment #2 from Reindl Harald <***@thelounge.net> ---
can we PLEASE get this bug fixed since it's root cause has a lot of
implications

in PHP header('Location: /something.php');on a site where you already are
connected via https:// also leadins in httpd redirect to
http://example.com/something.php with all sort of troubles

i can reproduce this issue every single day when login into a demo-cms on my
machine, the bookmark is https://, i just add cms/ tu the URL which redirect to
the login-page and voila you lost you https-url

[b***@apache.org]

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

Eric Covener <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO

--- Comment #3 from Eric Covener <***@gmail.com> ---
Tried to look at this, but curl couldn't access my 'SSLEngine optional'
vhost over https. Evidently 'SSLEngine optional' is meant to allow HTTPS
upgrade over HTTP, not just optionally doing normal TLS on the connection.

Some trick in your environment or envvar that influences curl?

[b***@apache.org]

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

--- Comment #4 from Reindl Harald <***@thelounge.net> ---
nothing special here, a lot of vhosts configured that way on Fedora 26 / Fedora
27 and it works also for any client as well as https://www.ssllabs.com/ssltest/

curl-7.55.1-10.fc27.x86_64
openssl-1.1.0g-1.fc27.x86_64
httpd-2.4.33-3.0.fc27.20180321.rh.sandybridge.x86_64
apr-1.6.3-6.0.fc27.20180318.rh.sandybridge.x86_64
apr-util-1.6.1-4.0.fc27.20180318.rh.sandybridge.x86_64

[b***@apache.org]

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

--- Comment #5 from Eric Covener <***@gmail.com> ---
(In reply to Reindl Harald from comment #4)

Post by b***@apache.org
nothing special here, a lot of vhosts configured that way on Fedora 26 /
Fedora 27 and it works also for any client as well as
https://www.ssllabs.com/ssltest/
curl-7.55.1-10.fc27.x86_64
openssl-1.1.0g-1.fc27.x86_64
httpd-2.4.33-3.0.fc27.20180321.rh.sandybridge.x86_64
apr-1.6.3-6.0.fc27.20180318.rh.sandybridge.x86_64
apr-util-1.6.1-4.0.fc27.20180318.rh.sandybridge.x86_64

Are you certain you're hitting the listed config and TLS isn't terminated
somewhere else? related but separately helpful, can you add a unique access
log to that vhost and append this to your logformat:

Host=%{Host}i localport=%{local}p L=%{Location}o Via=%{Via}i

to whatever your current logformat is?

[b***@apache.org]

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

--- Comment #6 from Reindl Harald <***@thelounge.net> ---
i can remember that you need at least *one* default host with "SSLEngine On" to
make mod_ssl initialize correctly and the others than can be combined ones

[***@srv-rhsoft:~]$ cat conf/sites_enabled/0000-default.conf
# letsencrypt-managed
<VirtualHost _default_:80>
<Location />
Require all denied
</Location>
<Location /.well-known>
Require all granted
</Location>
</VirtualHost>
<VirtualHost _default_:443>
ServerName default.local.rhsoft.net
ServerAlias default.rh.thelounge.net
SSLCertificateFile "/var/lib/letsencrypt/certs/0000-default.conf_rsa.pem"
SSLCertificateFile "/var/lib/letsencrypt/certs/0000-default.conf_ecdsa.pem"
SSLEngine On
<Location />
Require all denied
</Location>
<Location /.well-known>
Require all granted
</Location>
</VirtualHost>


i am 100% certain bcause i am the one-man-show serveradmin for the whole stack
from switches over virtualization down to the php software running on top

[b***@apache.org]

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

--- Comment #7 from Reindl Harald <***@thelounge.net> ---
practical example:

the folder /cms/ contains a "index.php" with header('Location: ../cms.php');

when you call the url with the traiing slash the relative redirect is
sent-as-is to the client and all is fine

without the trailing slash the typical httpd-redirect-behavior when calling
folders without a trailing slash is triggered and since httpd don't "know"
correctly about port/protocol somewhere deep insinde it redirects to http://

one could now say RFC mandates a fulkl-qualified redirect but the nature of
this bug makes this impossible because server-variables like
$_SERVER['SERVER_PORT'] giving 80 instead 443 to the script it's even not
possible to form a full-qualified URL within scripts

[***@srv-rhsoft:~]$ curl --head https://local.rhsoft.net/cms/
HTTP/1.1 302 Found
Date: Thu, 22 Mar 2018 11:54:17 GMT
Location: ../cms.php
X-Content-Type-Options: nosniff
X-Response-Time: D=2584 us
Cache-Control: no-cache, no-store
Vary: Accept-Encoding,User-Agent
Content-Type: text/html; charset=ISO-8859-1

[***@srv-rhsoft:~]$ curl --head https://local.rhsoft.net/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 22 Mar 2018 11:54:32 GMT
Location: http://local.rhsoft.net/cms/
Content-Type: text/html; charset=iso-8859-1

[b***@apache.org]

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

Post by b***@apache.org
this bug makes this impossible because server-variables like
$_SERVER['SERVER_PORT'] giving 80 instead 443 to the script it's even not
possible to form a full-qualified URL within scripts

yes, lots of stuff doesn't work with this unusual config. Is it worth putting
*:80 in the same VHost?

[b***@apache.org]

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

--- Comment #9 from Reindl Harald <***@thelounge.net> ---
it IS worth when you have some hundrets of virtual hosts on dozens of machines
which all have php_admin_value settings for open_basedir and so on and as we do
migrate to everything-encrypted with letsencrypt certificates

as you need to listen at port 80 even when you send HSTS headers and redirect
after the first non-ssl connection this would mean 500 additional cloned
<VirtualHost> definitions

in our case we decide via DNS if a domain goes over the TLS-offloading proxy or
if it is a low-traffic site directly to the apache server and so every
<VirtualHost> contains the construct below

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{CONN_REMOTE_ADDR} !^proxy-lan-ip
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>

proxy-configuration is generated based on parsed vhost-config-files from the
origins - including look at that redirect stuff to make the decision if the
procy itself should redirect to https before contact the origin at all

you *really* don't want to deal with hundrets of cloned VirtualHost-definiton
or even worse with special treatment instead of such a unified "fits all"
configuration

[b***@apache.org]

Dette indlæg kan være upassende. Klik for at få det vist.

[b***@apache.org]

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

--- Comment #11 from Eric Covener <***@gmail.com> ---
(In reply to Reindl Harald from comment #10)

Post by b***@apache.org
HTTPS on
REQUEST_SCHEME http

To recap, when you handshake with an "SSLEngine on" vhost then your request is
handled by an "SSLEngine optional" (which means starttls) vhost, these two
variables disagree and redirects send you to http://.

The former is set by ssl_hook_Fixup and looks for the SSL connection-level
config if the vhost has "sslengine optional".

The bits that go into fully-qualifying a redirect do not look to see if SSL is
currently active on the config:


static const char *ssl_hook_http_scheme(const request_rec *r)
{
SSLSrvConfigRec *sc = mySrvConfig(r->server);

if (sc->enabled == SSL_ENABLED_FALSE || sc->enabled ==
SSL_ENABLED_OPTIONAL) {
return NULL;
}

return "https";
}

static apr_port_t ssl_hook_default_port(const request_rec *r)
{
SSLSrvConfigRec *sc = mySrvConfig(r->server);

if (sc->enabled == SSL_ENABLED_FALSE || sc->enabled ==
SSL_ENABLED_OPTIONAL) {
return 0;
}

return 443;
}


I don't know if those decisions make sense for actual "SSLengine optional"
which is starttls, not simultaneous SSL and non-SSL. It looks like you've
misunderstood "SSLEngine optional" and are saving a few lines of copy/paste to
use a broken configuration. Maybe a different "optional" value is needed to
allow opt-in to this alt behavior for an obscure config.

Maybe someone else feels more confident about the safety and more willing to
put up with reading your unnecessarily dramatic updates.

[b***@apache.org]

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

--- Comment #12 from Reindl Harald <***@thelounge.net> ---
i doubt that "SSLengine optional" is STARTTLS, for sure not when you type
https:// in your browser - anyways, irrelevant, the port is just plain wrong
because with https:// the browser definitly don't connect to port 80 at all

the redirect to http:// because of a missing trailing slash wenn you call a
directory with a DirectoryIndex-file is wrong when "HTTPS on" is known

and this all is a real problem because it introuces all sorts of hidden
troubles and currently the only solution would be configure the whole
<VirtualHost> twice which don't scale for larger setups

i don't know the internals but they should not be that complex to begin with
that in this context any problems can be triggered when a client just calls
"https://example.com/myfolder" because the fact that it was https is obviously
known, the port itself is known on the network layer and REQUEST_SCHEME is
pretty simple known by the fact of "HTTPS on" is correct

what happens when you have <VirtualHost *:80 *:81 *:82> without https part of
the game? does then also 80 "win" and why when it's pretty simple to konw the
port by the fact that there is a socket connection and config-guessing is
pretty useless because of that

[b***@apache.org]

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

--- Comment #13 from Eric Covener <***@gmail.com> ---
(In reply to Reindl Harald from comment #12)

Post by b***@apache.org
i doubt that "SSLengine optional" is STARTTLS, for sure not when you type
https:// in your browser - anyways, irrelevant, the port is just plain wrong
because with https:// the browser definitly don't connect to port 80 at all

The manual says it's for starrtls, which you're not using, but it's what makes
the absolute basics of your specific config appear to work until a redirect is
generated.

Post by b***@apache.org
and this all is a real problem because it introuces all sorts of hidden
troubles and currently the only solution would be configure the whole
<VirtualHost> twice which don't scale for larger setups

It works for nearly everyone else.

Post by b***@apache.org
i don't know the internals but they should not be that complex to begin with
that in this context any problems can be triggered when a client just calls
"https://example.com/myfolder" because the fact that it was https is
obviously known, the port itself is known on the network layer and
REQUEST_SCHEME is pretty simple known by the fact of "HTTPS on" is correct

In the context of STARTTLS it seems reasonable. Optional was poorly named, but
it was clearly never meant to be used for requests that already negotiated SSL
at the connection level (in a default vhost).

Post by b***@apache.org
what happens when you have <VirtualHost *:80 *:81 *:82> without https part
of the game? does then also 80 "win" and why when it's pretty simple to konw
the port by the fact that there is a socket connection and config-guessing
is pretty useless because of that

No, the port or absence of a port in the Host: header "wins". Even getting the
port right is surprisingly not as simple as you'd think.

[b***@apache.org]

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

Post by b***@apache.org
It works for nearly everyone else

that's just an opinion - "nearly everyone else" don't look on the details and
mostly don't figure out from where random problems are coming or configures for
600 domains 1200 vhsost like a trained monkey

that scaled in times when you had a few https hosts becasue you needed time and
money for the certs but not now when Google announced that Chrome will start to
warn on every non-https page

anyways, i stell need to see any client that is using STARTTLS you are talking
the whole time about for http - when you type "https://example.com/directory"
there is no STARTTLS at all

at least your definition of STARTTLS is not compatible with the rest of the
world and protocols like IMAP/POP3/SMTP where STARTTLS is always teh default
service port and TLS/SSL is a different port - no browser is using anything
like that on Port 443 and we are not talking about anything similar when the
server listens on 443 and you type https:// in your client - port 80 is not
part of the game at all

Post by b***@apache.org
Even getting the port right is surprisingly not as simple as you'd think

why? i can't imagine anything simpler for a server than to determine the port
the client connected to

[b***@apache.org]

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

Post by b***@apache.org
anyways, i stell need to see any client that is using STARTTLS you are
talking the whole time about for http - when you type
"https://example.com/directory" there is no STARTTLS at all

The whole point is that you're using a configuration for STARTTLS but not using
STARTLS.

[b***@apache.org]

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

--- Comment #16 from Reindl Harald <***@thelounge.net> ---
even if - how does that justify a redirect from https://exmaple.com/cms to
http://example.com/cms/ which is a *downgrade* to unecrypted instead a *uprade*
to TLS

[b***@apache.org]

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

--- Comment #17 from Eric Covener <***@gmail.com> ---
(In reply to Reindl Harald from comment #16)

Post by b***@apache.org
even if - how does that justify a redirect from https://exmaple.com/cms to
http://example.com/cms/ which is a *downgrade* to unecrypted instead a
*uprade* to TLS

I assume STARTTLS would be used on an http port. So the other end is supposed
to cotinue using the upgraded connection or open and upgrade a new one. If you
just wanted them to connect over TLS to port 443 you wouldn't bother with
explicitly enabling STARTTLS.

[b***@apache.org]

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

If you just wanted them to connect over TLS to port 443 you
wouldn't bother with explicitly enabling STARTTLS

the whole point of the config is to have one instead two mostly redundant
<VirtualHost> and it works well besides a few issues

the redirect we are talking here about is this:
https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryslash

and *no* there is no valid reason when "HTTPS on" is correctly set within httpd
that this rediect goes to http:// - would you please stop argue about STARTTLS
which is *not* the topic at all

[b***@apache.org]

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

--- Comment #19 from Luca Toscano <***@gmail.com> ---
(In reply to Reindl Harald from comment #18)

Post by b***@apache.org
and *no* there is no valid reason when "HTTPS on" is correctly set within
httpd that this rediect goes to http:// - would you please stop argue about
STARTTLS which is *not* the topic at all

As already repeated a number of times in other places, please keep the tone of
the conversation in a way that is respectful of others work.

[b***@apache.org]

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

Eric Covener <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
Status|NEW |NEEDINFO

--- Comment #20 from Eric Covener <***@gmail.com> ---
Have you tried editing the Location: header if HTTPS=ON? Maybe it allows you to
continue to misuse "SSLEngine optional" without breaking anyone else.

Dropping severity as the config is invalid.

[b***@apache.org]

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

Reindl Harald <***@thelounge.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW

Post by b***@apache.org
Have you tried editing the Location: header if HTTPS=ON?

*please* take a short break and think abiut the issue as a wholöe
https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryslash

HTTPD does the redirect to http:// long before the script, so you can't prevent
a intermediate non-https connection which is extremely bad

[b***@apache.org]

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

--- Comment #22 from Reindl Harald <***@thelounge.net> ---
i try to explain it step by step:

* https://example.com/cms
* httpd redirects *before* any script to http://example.com/cms/
* after that 'index.php' is called the first time
* this conenction is no longer https
* HTTPS=ON is no longer true because of this

there is no possible workaround in any script

[b***@apache.org]

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

Eric Covener <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO

--- Comment #23 from Eric Covener <***@gmail.com> ---
(In reply to Reindl Harald from comment #21)

Post by b***@apache.org

Post by b***@apache.org
Have you tried editing the Location: header if HTTPS=ON?

*please* take a short break and think abiut the issue as a wholöe
https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryslash
HTTPD does the redirect to http:// long before the script, so you can't
prevent a intermediate non-https connection which is extremely bad

Seems like 'Header edit' ought to work, not sure what script you're talking
about.

[b***@apache.org]

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

--- Comment #24 from Joe Orton <***@redhat.com> ---
Possibly those two hooks should use the same logic as ssl_hook_Fixup

if (!(((sc->enabled == SSL_ENABLED_TRUE) || (sc->enabled ==
SSL_ENABLED_OPTIONAL)) && sslconn && (ssl = sslconn->ssl))) {
return DECLINED;
}

[b***@apache.org]

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

--- Comment #25 from Joe Orton <***@redhat.com> ---
Reindl, please try the patch from r1829250

[b***@apache.org]

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

--- Comment #26 from Reindl Harald <***@thelounge.net> ---
@Joe Orton thank you for step in

@Eric Covener

Post by b***@apache.org
Seems like 'Header edit' ought to work

that would be a config which don't solve the problem because it would redirect
to https even when the initial request was not - and for global configs: please
don't get me wrong but i don't get why we discuss that much forth and back when
https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryslash itself has to
look at the HTTPS=ON and send the correct redirect instead dirty workarounds


for me it seems that you have a personal problem when you see my name and if
that's the case please reconsider your behavior when we talk about technical
issues - please step back from your defensive attitude and let us focus on
technical details

Post by b***@apache.org
not sure what script you're talking about

the "index.php" which does the header('Location'); and not get
$_SERVER['HTTPS']

[b***@apache.org]

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

--- Comment #27 from Reindl Harald <***@thelounge.net> ---
@Joe Orton
https://svn.apache.org/viewvc?view=revision&revision=1829250

do i have too less coffee or is there no option to download the patch as a file
for rpmbuild's %patch macro?

[b***@apache.org]

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

--- Comment #28 from Joe Orton <***@redhat.com> ---
Try

https://github.com/apache/httpd/commit/8bfdfb336ad229380adc307265c78942d859787d.patch

but you'll probably need to adjust it for 2.4

[b***@apache.org]

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

--- Comment #29 from Reindl Harald <***@thelounge.net> ---
sorry but "but you'll probably need to adjust it for 2.4" is above my scope of
get the behavior of 2.4.33 fixed with a rpm-rebuild

+ echo 'Patch #4
(httpd-factor-out-logic-to-determine-if-request-is-using-ssl-tls.patch):'
Patch #4
(httpd-factor-out-logic-to-determine-if-request-is-using-ssl-tls.patch):
+ /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0
patching file modules/ssl/mod_ssl.c
Hunk #1 succeeded at 618 (offset -9 lines).
patching file modules/ssl/ssl_engine_kernel.c
Hunk #1 succeeded at 1336 (offset -166 lines).
Hunk #2 succeeded at 1346 (offset -166 lines).
patching file modules/ssl/ssl_private.h
Hunk #1 FAILED at 1096.
1 out of 1 hunk FAILED -- saving rejects to file modules/ssl/ssl_private.h.rej
patching file modules/ssl/ssl_util.c
Hunk #1 succeeded at 106 (offset 6 lines).

[b***@apache.org]

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

--- Comment #30 from Eric Covener <***@gmail.com> ---
(In reply to Reindl Harald from comment #26)

Post by b***@apache.org
@Joe Orton thank you for step in
@Eric Covener

Post by b***@apache.org
Seems like 'Header edit' ought to work

that would be a config which don't solve the problem because it would
redirect to https even when the initial request was not - and for global
configs: please don't get me wrong but i don't get why we discuss that much
forth and back when

The 'Header edit' can be conditionalseveral ways

Post by b***@apache.org
https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryslash itself has
to look at the HTTPS=ON and send the correct redirect instead dirty
workarounds

no, mod_dir should never do such a thing directly, that kind of thing doesn't
happen in each piece of code that might try to redirect. Your configuration is
deviant and there are simple ways to get it to actually work, but it's your
prerogative to try it or not.

Post by b***@apache.org
for me it seems that you have a personal problem when you see my name and if
that's the case please reconsider your behavior when we talk about technical
issues - please step back from your defensive attitude and let us focus on
technical details

I think I've been more than civil to you _despite_ your name. You are
incapable of inoffensive, non-hysterical technical discussion. Maybe you don't
know it. It is still a complete mystery how you can be so dependent and so
combatitive at the same time. I don't know what weird reward system or trauma
has reinforced this but I seriously suggest you reconsider your approach in
working with other humans.

Post by b***@apache.org

Post by b***@apache.org
not sure what script you're talking about

the "index.php" which does the header('Location'); and not get
$_SERVER['HTTPS']

Doesn't seem relevant to how the redirect happens or how it might be altered.

[b***@apache.org]

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

--- Comment #31 from Yann Ylavic <***@gmail.com> ---
Created attachment 35875
--> https://bz.apache.org/bugzilla/attachment.cgi?id=35875&action=edit
r1829250 against 2.4.33

Commit from comment 27 which applies to 2.4.33.

[b***@apache.org]

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

Post by b***@apache.org
I think I've been more than civil to you _despite_ your name.
You are incapable of inoffensive, non-hysterical technical discussion

your whole argumentation is "in my opinion you have to write 2 seperated
<VirtualHosts>" and "your config is unusual and i don't care"

https://bz.apache.org/bugzilla/show_bug.cgi?id=61519#c11
"Maybe someone else feels more confident about the safety and more willing to
put up with reading your unnecessarily dramatic update"

to be clear: so when you don't care at all please simply go away instead waste
both of our time and let some other person handle things - i wrote a bugreport
for httpd and not a letter to Eric Covener

[b***@apache.org]

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

Reindl Harald <***@thelounge.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEEDINFO |RESOLVED

--- Comment #33 from Reindl Harald <***@thelounge.net> ---
@Yann Ylavic:

* https://bz.apache.org/bugzilla/attachment.cgi?id=35875 works
* HTTPS on
* SERVER_PORT 443
* REQUEST_SCHEME https

all relevant environment variables are correct, redirect is correct, i will run
some tests but think that can be put in production here

THANK YOU!

[b***@apache.org]

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

--- Comment #34 from Yann Ylavic <***@gmail.com> ---
OK, but I kind of regret to have provided this patch now.

If you don't want help from the *team*, you won't get it anymore since, as Eric
said, you don't do much by yourself either. Strange strategy, may not last
eternally...

[b***@apache.org]

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

--- Comment #35 from Eric Covener <***@gmail.com> ---
(In reply to Reindl Harald from comment #32)

Post by b***@apache.org

Post by b***@apache.org
I think I've been more than civil to you _despite_ your name.
You are incapable of inoffensive, non-hysterical technical discussion

your whole argumentation is "in my opinion you have to write 2 seperated
<VirtualHosts>" and "your config is unusual and i don't care"

Not at all, I don't really have an argument here. I was curious what your
affected configuration was and even tested it. It took followups to ascertain
what that was.

I tried to provide you two different workarounds but you are myopically focused
on being "right" and playing some game that nobody else is playing.

Post by b***@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519#c11
"Maybe someone else feels more confident about the safety and more willing
to put up with reading your unnecessarily dramatic update"
to be clear: so when you don't care at all please simply go away instead
waste both of our time and let some other person handle things - i wrote a
bugreport for httpd and not a letter to Eric Covener

I do care about this bug for a variety of reasons, and I'm not about to take
communications advice from a renowned shit-poster.

[b***@apache.org]

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

--- Comment #36 from Reindl Harald <***@thelounge.net> ---
@Yann Ylavic

Post by b***@apache.org
If you don't want help from the *team*

this is simply not true - it's only about the back and forth discussion of Eric
in this bugreport with no intention to get that proper fixed as the patch does
and it pretty sure will fix a lot of other border-cases in mod_ssl

i simply don't understand why he steps in and argues back and forth with no
intention to get it fixed but talking only about all sorts of workarounds which
are not the intention of the bugreport

i can assure you that the whole community of http-users is waiting many years
and a lot of people will appreciate the oppotunity write a vhost config like
this

<VirtualHost *:80 *:443>
DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"
</VirtualHost>

[b***@apache.org]

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

--- Comment #37 from Yann Ylavic <***@gmail.com> ---
(In reply to Reindl Harald from comment #36)

Post by b***@apache.org
i simply don't understand why he steps in and argues back and forth with no
intention to get it fixed but talking only about all sorts of workarounds
which are not the intention of the bugreport

All I see in Eric's arguments is a way to make your case work, even if it's not
the way you'd like to. You care about your case, he cares about all the others
case too, which shouldn't be broken by arbitrary change in "optional"
semantics...

Post by b***@apache.org
i can assure you that the whole community of http-users is waiting many
years and a lot of people will appreciate the oppotunity write a vhost
config like this
<VirtualHost *:80 *:443>
DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"
</VirtualHost>

Surely true, though current "optional" (starttls) users wouldn't want their
different config to stop working. So you must accept that the team may have a
wider view on this, and that directives not meant to work like this in the
first place can't be reused at wish.
They are dev@ discussion on how we could do this with a generalization of
mod_md for instance, yet that may not be 2.4.x material because we care about
compatibility *for everyone* in a stable release.

[b***@apache.org]

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

--- Comment #38 from Reindl Harald <***@thelounge.net> ---
please see the first comment
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519#c1 which pretty much
explains "even if it's not the way you'd like to" from the begin

when $_SERVER['SERVER_PORT'] gives you 80 instead of 443 and you are on a setup
which uses 8080 and 8443 for wahtever reasons you are *not* able to construct a
full-qualified url without heuristics guessing when $_SERVER['HTTPS'] is 'on'
and $_SERVER['SERVER_PORT'] gives 8080 that you have to use 8443 for your URL
in a confirmation email

and you patch is fixing the whole issue which is finally more then the redirect
for URLs with a missing trailing slash

* HTTPS on
* SERVER_PORT 443
* REQUEST_SCHEME https

so it never was about "I tried to provide you two different workarounds but you
are myopically focused on being right and playing some game that nobody else is
playing" because i never play games

i focus real technical solutions instead workarounds not covering the issue as
a whole where it starts - not more and not less

[b***@apache.org]

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

--- Comment #39 from Eric Covener <***@gmail.com> ---
(In reply to Yann Ylavic from comment #37)

Post by b***@apache.org
(In reply to Reindl Harald from comment #36)

Post by b***@apache.org
i simply don't understand why he steps in and argues back and forth with no
intention to get it fixed but talking only about all sorts of workarounds
which are not the intention of the bugreport

All I see in Eric's arguments is a way to make your case work, even if it's
not the way you'd like to. You care about your case, he cares about all the
others case too, which shouldn't be broken by arbitrary change in "optional"
semantics...

Post by b***@apache.org
i can assure you that the whole community of http-users is waiting many
years and a lot of people will appreciate the oppotunity write a vhost
config like this
<VirtualHost *:80 *:443>
DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"
</VirtualHost>

A lot of people would appreciate that, but surely not the whole community is
waiting for it. With the patch, This still also requires a second, :443-only
VH as the default/first-listed for *:443 as we revealed in a later comment (due
to my intefering no less).

Two vhosts for SSL and non-SSL is not revolutionary. I think a single vhost
would be a good feature, and is similar to the non-LE mod_md stuff being
discussed on dev@ (which you are required to post under an alias on because of
your conflicts with people not named Eric Covener). But even this is not a
slam dunk if it introduces addl complexity and multiple ways to do the same
thing when there are already suitable options.

[b***@apache.org]

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

--- Comment #40 from Reindl Harald <***@thelounge.net> ---
is there any *technical* reason that the perfectly working
"factor-out-logic-to-determine-if-request-is-using-ssl-tls.patch" was not
included in 2.4.34?

[b***@apache.org]

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

Rainer Jung <***@kippdata.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |---
Status|RESOLVED |REOPENED

--- Comment #41 from Rainer Jung <***@kippdata.de> ---
The issue was closed by the OP as FIXED/RESOLVED in error when he added comment
#33.

We still need to decide, whether the backport patch for r1829250 (trunk by
jorton, backport by yann) gets applied (adding modssl_request_is_tls). It has
not yet been proposed in STATUS yet.

[b***@apache.org]

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

--- Comment #42 from William A. Rowe Jr. <***@apache.org> ---
I see a lot of conflated issues here.

The crux is that

1. A VirtualHost has one and only one port in httpd. This can be fixed in the
next major release with a list of possible ports and moving the port of
reference from the vhost to the conn struct.

2. SSLEngine Optional means processing the Upgrade: header to switch from http
to http over TLS. Nothing else. The port remains 80, obviously!


What I'm reading is that an unexpectedly successful attempt suggested support
for a facility which does not and cannot exist during 2.4.x. This has come up
on the dev list, and it seems the devs support the idea of multiple pontential
ports supported by a single vhost.

On the second point, because TLS is seen on the 443 connection, it is reported
as TLS, but is reporting the wrong port because the wrong vhost was elected.

[b***@apache.org]

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

--- Comment #43 from Reindl Harald <***@thelounge.net> ---
i don't see much issues here because it just works all the time and with the
patch even the correct port is reported over the whole stack

support for a facility which does not and cannot exist during 2.4.x

it already works and that you need the first defualt vhost with explicit
"SSLEngine On" is only a documentation issue and the only thing which needs
adopted from the moment this patch is included is the documentation

given that things like mod_h2 made it in 2.4.x i don#t see a reason why this
couldn't

[b***@apache.org]

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

Graham Leggett <***@apache.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|REOPENED |RESOLVED

--- Comment #44 from Graham Leggett <***@apache.org> ---
Backported to v2.4.38.

[b***@apache.org]

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

--- Comment #45 from Reindl Harald <***@thelounge.net> ---
Thank you!