> Am 17.12.2020 um 20:36 schrieb Yves Goergen <nospam.l...@unclassified.de>:
>
> I've tried this in the VirtualHost section of the dotforward.de domain,
> before any rewrites:
>
> <If "! %{HTTP_HOST} in { 'dotforward.de', 'www.dotforward.de' }">
> Redirect 421
> </If>
>
> It has no effect. I guess I'll have to report a software bug in Apache's
> HTTP2/mod_proxy implementation and hope for a fix to be made available in
> Ubuntu 20.04. Otherwise, HTTP2 will have to wait at least another 2 years.
My advice at this point would be:
Make a local setup that you can debug at your will and where other traffic does
not disturb. You can copy over your wildcard certificate and do tests with
> curl --resolve dotforward.de:443:<your-test-ip>
so there is no DNS tweaking necessary.
Next you would want to raise the log level of mod_proxy:
LogLevel proxy:trace2
LogLevel proxy_http:trace4
and you will see exactly which proxy handler is called and the responses from
your proxied apps in detail.
Regards, Stefan
>
> -Yves
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Stefan Eissing <stefan.eiss...@greenbytes.de>
> Gesendet: Donnerstag, 17. Dezember 2020, 14:41 MEZ
> Betreff: [users@httpd] Disable HTTP2 connection coalescing for different
> virtual hosts/domains
>
>
>
> 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
>
>
>
>
> ---------------------------------------------------------------------
> 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
