> Am 17.12.2020 um 14:05 schrieb Yves Goergen <nospam.l...@unclassified.de>:
>
> I found out I cannot use a test environment because it doesn't have wildcard
> certificates. So I had to quickly run this on the live server.
>
> Now I have a bunch of log lines about http2. What should I look for and how
> can I understand them? Please advise.
>
You should see log lines of the pattern:
[http2:debug] ... h2_task.c(83): [...] AH03348: h2_task(130-1): open output to
GET <hostname>:<port> <path>
where hostname, port and path specify what resource your browser requested,
irregardless on where the connection was started. If those host names look
correct, I would advise to look at the access log of your proxied server to see
which requests it sees.
Also, just for completeness, make sure your browser cache is empty and does not
carry resources from the time your server had an older, different config. You
can always use "curl" to get an honest opinion and with "-v" also some good
output of what actually happens on the client side.
Best regards,
Stefan
> -Yves
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Stefan Eissing <stefan.eiss...@greenbytes.de>
> Gesendet: Dienstag, 15. Dezember 2020, 15:24 MEZ
> Betreff: [users@httpd] Disable HTTP2 connection coalescing for different
> virtual hosts/domains
>
> Hi Yves,
>
> there is no "intentional" misdirecting by the spec or the server. Let's sort
> out where the problem lies and how to fix it.
>
> 1. You are correct that the browser will see your wildcard cert, see that it
> applies to another host and use the already open connection to make the
> request.
> 2. But the request should carry the hostname and thus forward it to your
> backend proxy, just like with http/1.1. And since you have "ProxyPreserveHost
> on" this should select the correct resources.
>
> How can we find out where things go wrong?
>
> - You could publish a different resource directly, without proxying in your
> vhosts and check that the correct one is seen in your browser. That would
> prove that the requests are made with the correct hostname.
> - If this is not the case, a log with "LogLevel http2:debug" would help to
> see what is wrong here.
> - But if this works, then the mixup happens somewhere in the proxy handling.
> What requests do you see incoming in your proxy logs in that case?
>
> Best regards, Stefan
>
>
> Am 15.12.2020 um 14:33 schrieb Yves Goergen <nospam.l...@unclassified.de>:
>
> Hello,
>
> I just found out the hard way that HTTP2 has a great new feature that
> intentionally misdirects requests to the wrong domain. I'm using Apache on
> Ubuntu 20.04 with Virtual Hosts, a single shared IPv4 address (what else can
> you do these days), HTTP2 and HTTPS. Some of these domains use the same
> wildcard certificate for the main domain and subdomains. Some of these
> virtual hosts also use a reverse proxy to a backend application server.
>
> When I open both these sites after another in Firefox, I always get the same
> content, even redirecting the second called domain back to the first. So that
> HTTP2 connection coalescing thing is clearly a critical bug in the spec or
> somewhere else that is expected to be worked around by each and every
> webserver admin. How sad. They did say they wanted to make it quicker. No
> word on safer or more reliable. Every optimisation is a tradeoff, this time
> it broke things.
>
> How should I do this now? I have the option to disable HTTP2 and deny the
> progress. It immediately resolves the issue. Or I could somehow somewhere
> make Apache respond with that 421 status code that teaches the browsers that
> this feature is bad and they should not use it. How could this be done? I
> wasn't able to find any resources about that. All sites' config files look
> similar to this:
>
>
> Listen [...IPv6...]:80
> <VirtualHost ...SharedIPv4...:80 [...IPv6...]:80>
> ServerName example.com
> ServerAlias www.example.com
> DocumentRoot /var/www/example/path
> RewriteEngine on
>
> # Redirection
> RewriteRule ^/(.*) https://example.com/$1 [L,R=301]
> <Directory "/var/www/example/path">
> Options +IncludesNOEXEC
> </Directory>
>
> # CGI/PHP (optional)
> SuexecUserGroup example webusers
> FcgidWrapper /var/www/php-bin/example/php-fcgi .php
> AddHandler fcgid-script .php
>
> # ASP.NET app (optional)
> ProxyPass "/" "http://127.0.0.1:7001/"; retry=5
> ProxyPassReverse "/" "http://127.0.0.1:7001/";
> ProxyPreserveHost on
> RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
> RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
> RewriteRule .* ws://127.0.0.1:7001%{REQUEST_URI} [P]
>
> RequestHeader set X-Forwarded-Proto "http"
> </VirtualHost>
>
> Listen [...IPv6...]:443
> <VirtualHost ...SharedIPv4...:443 [...IPv6...]:443>
> ServerName example.com
> ServerAlias www.example.com
> DocumentRoot /var/www/example/path
> RewriteEngine on
>
> # Redirection
> RewriteCond %{HTTP_HOST} !^example\.com(:443)?$ [NC]
> RewriteCond %{HTTP_HOST} !=""
> RewriteRule ^/(.*) https://example.com/$1 [L,R=301]
> <Directory "/var/www/example/path">
> Options +IncludesNOEXEC
> </Directory>
>
> # CGI/PHP (optional)
> SuexecUserGroup example webusers
> FcgidWrapper /var/www/php-bin/example/php-fcgi .php
> AddHandler fcgid-script .php
>
> # ASP.NET app (optional)
> ProxyPass "/" "http://127.0.0.1:7001/"; retry=5
> ProxyPassReverse "/" "http://127.0.0.1:7001/";
> ProxyPreserveHost on
> RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
> RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
> RewriteRule .* ws://127.0.0.1:7001%{REQUEST_URI} [P]
>
> RequestHeader set X-Forwarded-Proto "https"
>
> SSLEngine on
> SSLCertificateFile /etc/ssl/private/example.com
> SSLCertificateKeyFile /etc/ssl/private/example.com
> </VirtualHost>
>
>
> -Yves
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
