Apache 2.4 - Kein Indexing mit mod_http2

GwenDragon

GwenDragon

Registered User
Apache 2.4.25 - Debian 9.4 - libnghttp2 -1.18.1-1
Aus irgendeinem Grund funktioniert Indexes nicht mit http/2, nur mit http/1.1.
Die dazugehörige .htaccess
Code: 
IndexOptions Charset=utf-8 +FancyIndexing +HTMLTable +SuppressHTMLPreamble +SuppressRules +IgnoreClient +DescriptionWidth=* +ScanHTMLTitles 
IndexIgnore repo.ico login.html HEADER.html README.html
HeaderName /repo/HEADER.html
ReadmeName /repo/README.html

Options +Indexes
Sobald ich Option +Indexes aktivere, zeigt der http/2-fähige Browser einen SPDY_PROTOCOL_ERROR.
Clients über http/1.1 holen das Listing.

https://gwendragon.de/repo/repo.ico klappt mit http/2
https://gwendragon.de/repo/ schlägt fehl mit http/2

Das Serverlog der Domain zeigt nix.
Irgendeine Idee was das ist und wie das zu lösen wäre?
 
Last edited by a moderator:
Der Vollständigkeit halber:
Code: 
[root@devgate:~] # curl -v "https://gwendragon.de/repo/"
*   Trying 213.133.110.246...
* TCP_NODELAY set
* Connected to gwendragon.de (213.133.110.246) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=gwendragon.de
*  start date: May 18 08:30:02 2018 GMT
*  expire date: Aug 16 08:30:02 2018 GMT
*  subjectAltName: host "gwendragon.de" matched cert's "gwendragon.de"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x80487a280)
> GET /repo/ HTTP/2
> Host: gwendragon.de
> User-Agent: curl/7.60.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
* Connection #0 to host gwendragon.de left intact
curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)


Paketfilter/Firewalls sind auch gerne mögliche Ursachen, ebenso wie unfähige Backends (mod_perl ohne multithraeded Perl).

Welches MPM? MPM-Event ist gerade in Verbindung mit HTTP/2 eigentlich das Mittel der Wahl.
 
Um deine Frage zum Server wegen des Multi-Processing-Modules: MPM Event.
Udn wegen mod_perl. Das ist nicht aktiv.

Wieso meinst du es liegt an der CSP? Die existiert ja genauso für eine einzelne Datei als auch für den index wo es eben nicht klappt.

Das Problem tritt ja auf wo ein Index-Listing generiert werden muss.
 
Last edited by a moderator:
Danke, Joe für deine Hinweise.
Ich dachte mir schon, dass es ein ähnlich gelagerter Bug sein muss wie der von dir erwähnte Windows Apache.
Ich werde erstmal h2 abschalten, denn das Modul hat ist wohl im Status experimentell.

Vielleicht kann ich mit einer selbst kompilierten bzw. neueren Apache mehr erreichen. Werde ich auf dem Entwicklungsrechner in einer vM testen, ob es da noch auftritt.

Schönes Wochenende.
 
Last edited by a moderator:
Nein, kein H2Direct.

Wie gesagt, es läuft alles wunderbar ohne das abrupte Schließen der Connection auf allen anderen statischen/dynamischen Inhalten (PHP, Perl, Ruby).
Das Problem passiert nur auf Verzeichnissen wo ich das Indexlisting durch Apache generieren lassen will.
Ich denke, das ist ein Bug.
Ich werde mal ein Testcase in meiner VM aufbauen und sehen ob ich was an den Maintainer der Module melden kann.

Ich habe jetzt h2 erst mal rausgeworfen.
Schade, denn es hat ja viele Vorteile.
 
https://github.com/icing/mod_h2/issues/126 ist gleich als erster Bug mit Apache 2.4.26 gefixt worden: https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES
Code: 
 *) mod_http2: fixes https://github.com/icing/mod_h2/issues/126 e.g. beam bucket lifetime handling when data is sent over temporary pools.


Ebenso ist mod_http2 seit Apache 2.4.26 nicht mehr "experimental" sondern stable:
Code: 
 *) HTTP/2 support no longer tagged as "experimental" but is instead considered fully production ready.


Apache 2.4.25 ist bereits 8 Versionen beziehungsweise 17 Monate alt und seitdem wurden etliche wichtige Bugfixe eingepflegt, daher möchte man grundsätzlich nicht mit derart veralteten Versionen arbeiten, sondern immer mit der aktuellsten offiziellen Stable (derzeit 2.4.33).

Das ist halt das Problem mit Distros wie Debian und Ubuntu, man bekommt eben nur (wenn überhaupt) Sec-Fixes mit CVE-Nummer backportiert, nicht jedoch (wichtige) Bugfixes. Und auf aktuelle Softwareversionen wartet man dort eh generell vergeblich.
 
Du hast Recht! Ich schau mir mal das neuere Apache auf einer anderen Distrie an.

Danke für den Bug #126. :)
Und was den Bug auf Github anbelangt, ich habe so auf die Modulversion geschielt dass ich überlesen habe, dass Apache …26 dort gemeint war.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top