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>

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

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?

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

(In reply to Reindl Harald from comment #4)
> 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?

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

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

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

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

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

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

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

httpd has a completly split brain here


Apache Environment from phpinfo():
HTTPS on
SSL_TLS_SNI local.rhsoft.net
HTTP_HOST local.rhsoft.net
SERVER_NAME local.rhsoft.net
SERVER_PORT 80
REQUEST_SCHEME http

focus on the "HTTPS" which is corrent versus wrong "SERVER_PORT" and "REQUEST_SCHEME" - thi smakes it possible to put some hacks in php-libraries and overwrite it so that most scripts behave correctly

but you can't hack the wrong redirect to http:// when one tries to access a folder without the trailing slash because that redirect is done by httpd itself and fianlyl you have a *real probem* in your client becasue proper sent cookies with secure-Flags are gone, logins don#t work, you don't realize that you unintenionally switched to unecnrypted and that leads to support calls for every single vhost which get mirgated to dual-stack and letsencrypt

you *clearly* know the fact it's https, so REQUEST_SCHEME is easily to fix and you know the incoming port from the network layer - frankly there is no sane reason to get that wrong and set it to 80 when the lcient is connected to 443

(In reply to Reindl Harald from comment #10)

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

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

(In reply to Reindl Harald from comment #12)
> 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.

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

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


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

> 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

> 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

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

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

(In reply to Reindl Harald from comment #16)
> 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.

> 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

(In reply to Reindl Harald from comment #18)
>
> 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.

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.

> 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

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

(In reply to Reindl Harald from comment #21)
> > 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.

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

Reindl, please try the patch from r1829250

@Joe Orton thank you for step in

@Eric Covener

> 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

> not sure what script you're talking about

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

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

Try

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

but you'll probably need to adjust it for 2.4

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

(In reply to Reindl Harald from comment #26)
> @Joe Orton thank you for step in
> 
> @Eric Covener
> 
> > 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

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

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

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

Created attachment 35875 [details]
r1829250 against 2.4.33

Commit from comment 27 which applies to 2.4.33.

@Eric Covener:


> 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

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

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

(In reply to Reindl Harald from comment #32)
> @Eric Covener:
> 
> 
> > 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.

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

@Yann Ylavic

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

(In reply to Reindl Harald from comment #36)
> 
> 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...

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

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

(In reply to Yann Ylavic from comment #37)
> (In reply to Reindl Harald from comment #36)
> > 
> > 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...
> 
> > 
> > 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.

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?

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.

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.

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

Backported to v2.4.38.

Thank you!