RE: [users@httpd] Ratelimiting Apache File Upload Speed [EXT]

2020-12-17 Thread James Smith
Why do you want to rate limit the upload speed to your server - slow upload 
speeds tend to be the thing that causes Apache issues rather than the other way 
round.

If it is because your server is on a narrow pipe and you are worried about 
being swamped by one connection - then rate limiting won't change anything the 
user sending large amounts of data will still send it - it will just be 
processed slower by apache.


-Original Message-
From: Gryzli Bugbear  
Sent: 14 December 2020 15:19
To: users@httpd.apache.org
Subject: [users@httpd] Ratelimiting Apache File Upload Speed [EXT]

Hi guys,

Is there a way to limit/ratelimit the upload speed to Apache ?

I'm searching for a way to ratelimit the upload speed per IP address, or even 
better per IP , per Location.

Regards,

--
-- Gryzli

https://urldefense.proofpoint.com/v2/url?u=https-3A__gryzli.info=DwICaQ=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=oH2yp0ge1ecj4oDX0XM7vQ=5JaH_y-SK3nU12rslEDlsjoxZCLMEd56ZsV0dxYbTfk=ai1CndtV8RADJ9lgTPhJxnucBOsVw2VBcranFGKYDrI=
 


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org




-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.

Re: [users@httpd] Ratelimiting Apache File Upload Speed

2020-12-17 Thread Gryzli Bugbear
No, I've already checked upon mod_ratelimit, mod_bwlimit, they work only 
with outgoing traffic (Apache --> Client ).


Didn't find any solution, that's able to do incoming traffic shaping 
(Client --> Apache,  upload traffic for the client).


On 12/17/20 4:37 PM, Daniel Ferradal wrote:

Check if this suits your needs. It is pretty straight forward.

http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

El lun, 14 dic 2020 a las 16:20, Gryzli Bugbear
() escribió:

Hi guys,

Is there a way to limit/ratelimit the upload speed to Apache ?

I'm searching for a way to ratelimit the upload speed per IP address, or
even better per IP , per Location.

Regards,

--
-- Gryzli

https://gryzli.info


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org




--
-- Gryzli

https://gryzli.info


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] Alternative to Let's Encrypt?

2020-12-17 Thread Daniel Armando Rodriguez
Will take a look to MD and the acme.sh.

Thank you all




El jue., 17 de diciembre de 2020 16:23, Nikolai Lusan 
escribió:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hey,
>
> On Thu, 2020-12-17 at 12:39 -0300, Daniel Armando Rodriguez wrote:
> > Is there any?
>
> Sure, you can pay for certificates from vendors like Comodo.
>
>
> > Asking because don't want to use snap.
>
> Not sure what this has to do with anything. There are several clients
> that you can use to create letsencrypt certificates, not all of the are
> certbot. Personally I use acme.sh - have a look at
> https://letsencrypt.org/docs/client-options/
>
>
> - --
> Nikolai Lusan 
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAl/br9cACgkQ4ZaDRV2V
> L6TBnxAAnXUNX2b5BE/DN3ZTwjzHGxr9yXrp9gJVIg2p9Tn57F5kf+r8ik0wR+pG
> rhv4HdtAscByd6Xzoci1rYNgov34IE0vpbKmMuUSXDUmXkgQmrkTMZlOY6mSToDa
> 6OOJcE7JWAH+wAKkaFJJKCnUj+l9mbJ8nnoOW6UfaR3GnLVktZLo7Cps0yVG82SR
> 7vGlzbmMfxRPDTWah3PBJgonnolRMSCEP0mCRX1n1HkEBaV3+83tOKfbqE9iFk1D
> z+kntVV7/cv33FahJVUr1yLwdgw9HlGWb1+Ro1c8SkF2jt6A5UMz+hbcNpsEOQc6
> EAubXBeMwkXs2mZCG/9WLHr5Ys5tgs99hRpJNkJ+RyuCu0LGM9XbFh5l3X//vkJH
> lV5glZEfkuCpcoWaB0ukflMy6U5v1WVBXviOHOK65WbZWfIXZ8Otd08mZfrn40Eg
> RIZ7GL60onITNNjO1CLm3Z5+zmF9nvBfyGO2QyJfJUiKKMO/0/NCK9iVB3S2Rcw9
> T8NRmgycckzxlvIpsW8ySSEj05MMOWxOZbigF5NfQpwSxdFjY89hlK7HPEI2HTrr
> awKCGexAiIwxndGE7gplZtZcM8+zkm18ZbltLzjooYBB62UfzhSnLfnfBXNF1zA5
> jqm+EzvwjvXl2/aYvfZf7AsptQhSDVu/avnZ5yKPM6BMXDI35AY=
> =cGH7
> -END PGP SIGNATURE-
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>


Re: [users@httpd] Disable HTTP2 connection coalescing for different virtual hosts/domains

2020-12-17 Thread Yves Goergen
I've tried this in the VirtualHost section of the dotforward.de domain, 
before any rewrites:



   Redirect 421


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.


-Yves


 Ursprüngliche Nachricht 
Von: Stefan Eissing 
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 :

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 : 


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

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

ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example/path
RewriteEngine on

# Redirection
RewriteRule ^/(.*) https://example.com/$1 [L,R=301]

Options +IncludesNOEXEC


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

Re: [users@httpd] Alternative to Let's Encrypt?

2020-12-17 Thread Nikolai Lusan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey,

On Thu, 2020-12-17 at 12:39 -0300, Daniel Armando Rodriguez wrote:
> Is there any?

Sure, you can pay for certificates from vendors like Comodo.


> Asking because don't want to use snap.

Not sure what this has to do with anything. There are several clients
that you can use to create letsencrypt certificates, not all of the are
certbot. Personally I use acme.sh - have a look at
https://letsencrypt.org/docs/client-options/


- -- 
Nikolai Lusan 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAl/br9cACgkQ4ZaDRV2V
L6TBnxAAnXUNX2b5BE/DN3ZTwjzHGxr9yXrp9gJVIg2p9Tn57F5kf+r8ik0wR+pG
rhv4HdtAscByd6Xzoci1rYNgov34IE0vpbKmMuUSXDUmXkgQmrkTMZlOY6mSToDa
6OOJcE7JWAH+wAKkaFJJKCnUj+l9mbJ8nnoOW6UfaR3GnLVktZLo7Cps0yVG82SR
7vGlzbmMfxRPDTWah3PBJgonnolRMSCEP0mCRX1n1HkEBaV3+83tOKfbqE9iFk1D
z+kntVV7/cv33FahJVUr1yLwdgw9HlGWb1+Ro1c8SkF2jt6A5UMz+hbcNpsEOQc6
EAubXBeMwkXs2mZCG/9WLHr5Ys5tgs99hRpJNkJ+RyuCu0LGM9XbFh5l3X//vkJH
lV5glZEfkuCpcoWaB0ukflMy6U5v1WVBXviOHOK65WbZWfIXZ8Otd08mZfrn40Eg
RIZ7GL60onITNNjO1CLm3Z5+zmF9nvBfyGO2QyJfJUiKKMO/0/NCK9iVB3S2Rcw9
T8NRmgycckzxlvIpsW8ySSEj05MMOWxOZbigF5NfQpwSxdFjY89hlK7HPEI2HTrr
awKCGexAiIwxndGE7gplZtZcM8+zkm18ZbltLzjooYBB62UfzhSnLfnfBXNF1zA5
jqm+EzvwjvXl2/aYvfZf7AsptQhSDVu/avnZ5yKPM6BMXDI35AY=
=cGH7
-END PGP SIGNATURE-


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] Alternative to Let's Encrypt?

2020-12-17 Thread Yehuda Katz
You can install certbot in a python virtualenv from pypi. This is
technically not supported, but it does work.
https://pypi.org/project/certbot/

See other alternate installation methods:
https://certbot.eff.org/docs/install.html

You can also use mod_md to have all the certificate generation handled by
HTTPD: http://httpd.apache.org/docs/2.4/mod/mod_md.html

On Thu, Dec 17, 2020 at 10:40 AM Daniel Armando Rodriguez <
drodrig...@epet1.edu.ar> wrote:

> Is there any?
> Asking because don't want to use snap.
>


Re: [users@httpd] some questions to mod_rewrite

2020-12-17 Thread Lentes, Bernd



- On Dec 17, 2020, at 5:19 PM, Daniel Ferradal dferra...@apache.org wrote:

> Hey Bernd,
> 
> I remember my first head scratches with regex, they can be so
> confusing and difficult to understand.
> 
> Although I remember preciously the day https://regexone.com/ opened my
> eyes. It just took me 45 minutes to understand the basics of it.
> 
> I dearly recommend you to do the same and visit the site, once you
> grasp it, regex will be tones of times easier to deal with.
> 
> Cheers
> 

Hi Daniel,

my problems are more the understanding of RewriteRule in vhost- or 
per-directory context.
I try to understand how rewriting works in a up-to-date Nextcloud.

This is the scenario:

root@nc-mcd:~# ll /var/www/nextcloud
total 116
drwxr-x--- 1 www-data www-data   396 Dec  9 20:33 ./
drwxr-xr-x 1 root root90 Dec 14 19:01 ../
drwxr-x--- 1 www-data www-data   778 Dec  9 20:33 3rdparty/
drwxr-x--- 1 www-data www-data  1154 Dec 14 22:20 apps/
-rw-r- 1 www-data www-data 17234 Dec  9 20:30 AUTHORS
drwxr-x--- 1 www-data www-data72 Dec 14 19:08 config/
-rw-r- 1 www-data www-data  3893 Dec  9 20:30 console.php
-rw-r- 1 www-data www-data 34520 Dec  9 20:30 COPYING
drwxr-x--- 1 www-data www-data   458 Dec  9 20:33 core/
-rw-r- 1 www-data www-data  5083 Dec  9 20:30 cron.php
-rw-r- 1 www-data www-data  4450 Dec 14 19:08 .htaccess  <==
-rw-r- 1 www-data www-data   156 Dec  9 20:30 index.html
-rw-r- 1 www-data www-data  2960 Dec  9 20:30 index.php
drwxr-x--- 1 www-data www-data   126 Dec  9 20:30 lib/
-rw-r- 1 www-data www-data   283 Dec  9 20:30 occ
drwxr-x--- 1 www-data www-data18 Dec  9 20:30 ocm-provider/
drwxr-x--- 1 www-data www-data50 Dec  9 20:30 ocs/
drwxr-x--- 1 www-data www-data18 Dec  9 20:30 ocs-provider/
-rw-r- 1 www-data www-data  3102 Dec  9 20:30 public.php
-rw-r- 1 www-data www-data  5332 Dec  9 20:30 remote.php
drwxr-x--- 1 www-data www-data   158 Dec  9 20:30 resources/
-rw-r- 1 www-data www-data26 Dec  9 20:30 robots.txt
-rw-r- 1 www-data www-data  2379 Dec  9 20:30 status.php
drwxr-x--- 1 www-data www-data26 Dec  9 20:30 themes/
drwxr-x--- 1 www-data www-data42 Dec  9 20:31 updater/
-rw-r- 1 www-data www-data   101 Dec  9 20:30 .user.ini
-rw-r- 1 www-data www-data   362 Dec  9 20:33 version.php

There is a .htaccess in the folder.
So per-directory context. Now from the official apache documentation:

What is matched ?
 ...
"In per-directory context (Directory and .htaccess), the Pattern is matched 
against only a partial path, for example a request of "/app1/index.html" may 
result in comparison against "app1/index.html" or "index.html" depending on 
where the RewriteRule is defined.
The directory path where the rule is defined is stripped from the currently 
mapped filesystem path before comparison (up to and including a trailing 
slash)."

So in this case this would mean, as the .htaccess file is in 
/var/www/nextcloud/, this path (/var/www/nextcloud/) is stripped before 
comparing.

"The net result of this per-directory prefix stripping is that rules in this 
context only match against => the portion of the currently mapped 
FILESYSTEM PATH "below" <=== where the rule is defined.
I understand it that way that a request of /somepath/somefile, which mapps 
maybe via an alias to /var/www/nextcloud/ looks now IN THE FILESYSTEM for 
somepath/somefile below /var/www/nextcloud/
That's my understanding and afters hours of fighting with rewrite i was happy 
and proud to get it. But ...

Here are the some rewriterules from that .htaccess:

  RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json 
[QSA,L]
  RewriteRule ^\.well-known/webfinger /public.php?service=webfinger [QSA,L]
  RewriteRule ^\.well-known/nodeinfo /public.php?service=nodeinfo [QSA,L]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
  RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

Let's take the first rule:
RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
Following my assumption (the rule is defined in a .htaccess in 
/var/www/nextcloud, so /var/www/nextcloud/ is stripped), the pattern 
'^\.well-known/host-meta' is matched again the filesystem "below" the .htaccess.
But there is no folder ".well-known.
And the other rules: there are no folders remote/, no folder or file named 
build, tests, config, lib, ...
Then all these rules wouldn't make sense !?!

I thought i got it, but now i'm completely stunned.
Can someone bring light into it ? Is my understanding wrong, that in 
per-directory context the pattern is matched 

Re: [users@httpd] Disable HTTP2 connection coalescing for different virtual hosts/domains

2020-12-17 Thread Yves Goergen

Okay, the log has lines such as these:


2020-12-17 14:01:57.397341 - - debug http2 2003:d5:72f:...: AH03348: 
h2_task(70-15): open output to GET dotforward.de /


Then 2 seconds later when I opened the subdomain:


2020-12-17 14:01:59.413740 - - debug http2 2003:d5:72f:...: AH03082: 
h2_stream(70-31,IDLE): created
2020-12-17 14:01:59.413754 - - debug http2 2003:d5:72f:...: AH03078: 
h2_session(70,BUSY,1): transit [IDLE] -- stream change --> [BUSY]
2020-12-17 14:01:59.413783 - - debug http2 2003:d5:72f:...: AH03066: 
h2_session(70,BUSY,1): recv FRAME[HEADERS[length=590, hend=1, stream=31, 
eos=1]], frames=31/99 (r/s)
2020-12-17 14:01:59.413789 - - debug http2 2003:d5:72f:...: AH03066: 
h2_session(70,BUSY,1): recv FRAME[WINDOW_UPDATE[stream=31, incr=12451840]], 
frames=32/99 (r/s)
2020-12-17 14:01:59.413913 - - debug http2 2003:d5:72f:...: AH03348: 
h2_task(83-31): open output to GET control.dotforward.de /
2020-12-17 14:01:59.413946 - - debug http2 2003:d5:72f:...: AH03073: 
h2_stream(70-31,HALF_CLOSED_REMOTE): submit response 301, 
REMOTE_WINDOW_SIZE=12582912
2020-12-17 14:01:59.413958 - - debug http2 2003:d5:72f:...: AH02936: 
h2_stream(70-31,HALF_CLOSED_REMOTE): resumed
2020-12-17 14:01:59.413967 - - debug http2 2003:d5:72f:...: AH03068: 
h2_session(70,BUSY,1): sent FRAME[HEADERS[length=76, hend=1, stream=31, 
eos=0]], frames=33/100 (r/s)
2020-12-17 14:01:59.413974 - - debug http2 2003:d5:72f:...: AH03068: 
h2_session(70,BUSY,1): sent FRAME[DATA[length=230, flags=1, stream=31, 
padlen=0]], frames=33/101 (r/s)
2020-12-17 14:01:59.414017 - - debug http2 2003:d5:72f:...: 
beam(83-31,output,closed=1,aborted=1,empty=1,buf=0): AH03385: h2_task_destroy, 
reuse secondary
2020-12-17 14:01:59.414056 - - debug http2 2003:d5:72f:...: AH03078: 
h2_session(70,IDLE,0): transit [BUSY] -- no io (keepalive) --> [IDLE]
2020-12-17 14:01:59.447946 - - debug http2 2003:d5:72f:...: AH03082: 
h2_stream(70-33,IDLE): created
2020-12-17 14:01:59.447959 - - debug http2 2003:d5:72f:...: AH03078: 
h2_session(70,BUSY,1): transit [IDLE] -- stream change --> [BUSY]
2020-12-17 14:01:59.447975 - - debug http2 2003:d5:72f:...: AH03066: 
h2_session(70,BUSY,1): recv FRAME[HEADERS[length=22, hend=1, stream=33, 
eos=1]], frames=33/101 (r/s)
2020-12-17 14:01:59.447981 - - debug http2 2003:d5:72f:...: AH03066: 
h2_session(70,BUSY,1): recv FRAME[WINDOW_UPDATE[stream=33, incr=12451840]], 
frames=34/101 (r/s)
2020-12-17 14:01:59.449109 - - debug http2 2003:d5:72f:...: AH03348: 
h2_task(87-33): open output to GET dotforward.de /
2020-12-17 14:01:59.449134 - - debug http2 2003:d5:72f:...: AH03073: 
h2_stream(70-33,HALF_CLOSED_REMOTE): submit response 200, 
REMOTE_WINDOW_SIZE=12582912
2020-12-17 14:01:59.449147 - - debug http2 2003:d5:72f:...: AH02936: 
h2_stream(70-33,HALF_CLOSED_REMOTE): resumed
2020-12-17 14:01:59.449153 - - debug http2 2003:d5:72f:...: AH03068: 
h2_session(70,BUSY,1): sent FRAME[HEADERS[length=6, hend=1, stream=33, eos=0]], 
frames=35/102 (r/s)
2020-12-17 14:01:59.449160 - - debug http2 2003:d5:72f:...: AH03068: 
h2_session(70,BUSY,1): sent FRAME[DATA[length=1291, flags=0, stream=33, 
padlen=0]], frames=35/103 (r/s)
2020-12-17 14:01:59.449164 - - debug http2 2003:d5:72f:...: AH03068: 
h2_session(70,BUSY,1): sent FRAME[DATA[length=1291, flags=0, stream=33, 
padlen=0]], frames=35/104 (r/s)
2020-12-17 14:01:59.449169 - - debug http2 2003:d5:72f:...: AH03068: 
h2_session(70,BUSY,1): sent FRAME[DATA[length=359, flags=1, stream=33, 
padlen=0]], frames=35/105 (r/s)
2020-12-17 14:01:59.449215 - - debug http2 2003:d5:72f:...: 
beam(87-33,output,closed=1,aborted=1,empty=1,buf=0): AH03385: h2_task_destroy, 
reuse secondary
2020-12-17 14:01:59.449241 - - debug http2 2003:d5:72f:...: AH03078: 
h2_session(70,IDLE,0): transit [BUSY] -- no io (keepalive) --> [IDLE]
2020-12-17 14:02:04.449869 - - debug http2 2003:d5:72f:...: AH03068: 
h2_session(70,IDLE,0): sent FRAME[GOAWAY[error=0, reason='timeout', 
last_stream=33]], frames=35/106 (r/s)
2020-12-17 14:02:04.449936 - - debug http2 2003:d5:72f:...: AH03069: 
h2_session(70,IDLE,0): sent GOAWAY, err=0, msg=timeout
2020-12-17 14:02:04.449942 - - debug http2 2003:d5:72f:...: AH03078: 
h2_session(70,DONE,0): transit [IDLE] -- local goaway --> [DONE]
2020-12-17 14:02:04.449945 - - debug http2 2003:d5:72f:...: AH03078: 
h2_session(70,CLEANUP,0): transit [DONE] -- pre_close --> [CLEANUP]


So Apache sees that I want to get something else.

I've erased my browser cache several times during these tests. I first 
suspected that Firefox has a bug and loads different domains on its own, 
as clearing the cache didn't help often. But it seems it's HTTP2's fault.


When the wrong site loads, Firefox shows a 301 redirect to the previous 
domain. This is pretty nasty in the browser cache so I have to erase it 
after such a situation.


The proxied apps do not have an access log. I can't see what requests 
they get. But none of the apps know about their public domain so how 
should they somehow act on it?


This 

Re: [users@httpd] some questions to mod_rewrite

2020-12-17 Thread Daniel Ferradal
Hey Bernd,

I remember my first head scratches with regex, they can be so
confusing and difficult to understand.

Although I remember preciously the day https://regexone.com/ opened my
eyes. It just took me 45 minutes to understand the basics of it.

I dearly recommend you to do the same and visit the site, once you
grasp it, regex will be tones of times easier to deal with.

Cheers

El mar, 15 dic 2020 a las 17:42, Lentes, Bernd
() escribió:
>
>
> - On Dec 11, 2020, at 4:13 PM, Eric Covener cove...@gmail.com wrote:
>
> > On Fri, Dec 11, 2020 at 10:06 AM Lentes, Bernd
> >  wrote:
> >>
> >> - On Dec 9, 2020, at 6:02 PM, Eric Covener cove...@gmail.com wrote:
> >>
> >> Hi Eric,
> >>
> >> thanks for your answer.
> >> Now i'm struggling with RewriteRule
> >> ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
> >>
> >> Most is clear. The content of the parentheses () like build, tests .. is
> >> or-conjuncted by the pipe |,
> >> so only one of the patterns must appear.
> >> But what is ?: ?
> >
> > It makes the () "non-capturing" meaning if you had other () sequences
> > this or-conjunction would not eat up $1.
> > In the case above it is unnecessary since there is no other capture.
> >
> >> The question mark normally is a repeater for the prior character. But 
> >> there is
> >> no one.
> >> And wherefore is the colon ?
> >
> > It's a special case when following "(". It allows the
> > matching/capturing to be customized a few different ways (man
> > pcresyntax has a concise list of the flags that follow "(?")
> >
> >> I gave https://perldoc.perl.org/perlre#Metacharacters a chance. It seems 
> >> the ?:
> >> says that a match for (build|tests|config|lib|3rdparty|templates)
> >> can't be used as a backreference. Right ? Where is the purpose of that ?
> >
> > yes, just to avoid eating up $1. But some people do it out of habit
> > when they use () just to group "|".
> >
> >
> >> in my error_log with setting "LogLevel info rewrite:trace2":
> >> [Fri Dec 11 15:44:50.666869 2020] [rewrite:trace1] [pid 3408]
> >> mod_rewrite.c(483): [client 146.107.126.166:57329] 146.107.126.166 - -
> >> [nc-mcd.helmholtz-muenchen.de/sid#7f9158e4f700][rid#7f9155a2a0a0/initial]
> >> [perdir /var/www/nextcloud/] pass through /var/www/nextcloud/
> >>
> >> What is sid and rid ?
> >
> > server (vhost) id and request id i believe. Usually not so useful.
> > The /initial meant it's not a "subrequest" (a way apache modules
> > sometimes make an internal request related to the real request to
> > probe for things)
> >
>
> Hi,
>
> some more questions:
>
> 1. What is if a rule matched and a substitution occured ? When there are 
> following rules, they are compared with the substitution, right ?
> 2. What is if a rule matched and a substitution occured ? Does Apache 
> continues with the next rule or does it start from scratch with the first 
> rule again ?
> 3. Let's assume we have a vhost with a conf file, and in the documentroot of 
> the vhost a .htaccess file. In both files are RewriteRules.
>   In which order are they processed ?
>
>
> Bernd
> Helmholtz Zentrum München
>
> Helmholtz Zentrum Muenchen
> Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
> Ingolstaedter Landstr. 1
> 85764 Neuherberg
> www.helmholtz-muenchen.de
> Aufsichtsratsvorsitzende: MinDir.in Prof. Dr. Veronika von Messling
> Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Kerstin Guenther
> Registergericht: Amtsgericht Muenchen HRB 6466
> USt-IdNr: DE 129521671
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>


-- 
Daniel Ferradal
HTTPD Project
#httpd help at Freenode

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] Alternative to Let's Encrypt?

2020-12-17 Thread Daniel Ferradal
Not sure what you mean by snap.

If you refer to not using let's encrypt certbot you can use mod_md:
http://httpd.apache.org/docs/2.4/mod/mod_md.html

Otherwise I don't know of any alternative to let's encrypt service
with similar characteristics.

El jue, 17 dic 2020 a las 16:48, Daniel Armando Rodriguez
() escribió:
>
> Is there any?
> Asking because don't want to use snap.



-- 
Daniel Ferradal
HTTPD Project
#httpd help at Freenode

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



[users@httpd] Alternative to Let's Encrypt?

2020-12-17 Thread Daniel Armando Rodriguez
Is there any?
Asking because don't want to use snap.


Re: [users@httpd] Ratelimiting Apache File Upload Speed

2020-12-17 Thread Daniel Ferradal
Check if this suits your needs. It is pretty straight forward.

http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

El lun, 14 dic 2020 a las 16:20, Gryzli Bugbear
() escribió:
>
> Hi guys,
>
> Is there a way to limit/ratelimit the upload speed to Apache ?
>
> I'm searching for a way to ratelimit the upload speed per IP address, or
> even better per IP , per Location.
>
> Regards,
>
> --
> -- Gryzli
>
> https://gryzli.info
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>


-- 
Daniel Ferradal
HTTPD Project
#httpd help at Freenode

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] Disable HTTP2 connection coalescing for different virtual hosts/domains

2020-12-17 Thread Stefan Eissing



> Am 17.12.2020 um 14:05 schrieb Yves Goergen :
> 
> 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 : 

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 
> 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 :
> 
> 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
> 
>   ServerName example.com
>   ServerAlias www.example.com
>   DocumentRoot /var/www/example/path
>   RewriteEngine on
> 
>   # Redirection
>   RewriteRule ^/(.*) https://example.com/$1 [L,R=301]
>   
>   Options +IncludesNOEXEC
>   
> 
>   # 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"
> 
> 
> Listen [...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]
>   
>   

Re: [users@httpd] Disable HTTP2 connection coalescing for different virtual hosts/domains

2020-12-17 Thread Yves Goergen
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.


-Yves


 Ursprüngliche Nachricht 
Von: Stefan Eissing 
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 :

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

ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example/path
RewriteEngine on

# Redirection
RewriteRule ^/(.*) https://example.com/$1 [L,R=301]

Options +IncludesNOEXEC


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


Listen [...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]

Options +IncludesNOEXEC


# 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



-Yves

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, 

Re: [users@httpd] Disable HTTP2 connection coalescing for different virtual hosts/domains

2020-12-17 Thread Yves Goergen
The issue also occurs when switching between a regular Apache-hosted 
site to a proxied service. Requests to the proxied app then end up in 
Apache itself and never reach the proxy app.


I'll try to update my test machine and get the logging to work. 
Activating that on the live server probably produces way too much data 
and overflows everyone.


BTW, can somebody please configure my mailing list subscription to also 
send me my own messages? I cannot see my messages here, only others'.


-Yves


 Ursprüngliche Nachricht 
Von: Stefan Eissing 
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 :

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

ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example/path
RewriteEngine on

# Redirection
RewriteRule ^/(.*) https://example.com/$1 [L,R=301]

Options +IncludesNOEXEC


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


Listen [...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]

Options +IncludesNOEXEC


# 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