Verwendet Discourse keine Brotli- oder Gzip-Komprimierung?

Unterstützung Installation
1

Hallo. Ich habe Discourse auf einem CentOS-Server installiert. Ich verwende auch das CentOS Web Panel.

Es scheint, als wären die Dateien in Discourse nicht komprimiert, obwohl standardmäßig Brotli verwendet werden und im Fallback auf gzip zurückgegriffen werden sollte.

Beispiel für diese Datei mit einer Größe von 2,2 MB:
https://forum.canapin.win/assets/application-301651b1c7400a000974a9cecafd44ad3304cf647cf17bcfa7af68e9ed1ac4b7.js

Response Headers:
    accept-ranges: bytes
    cache-control: max-age=31536000
    cache-control: public,immutable
    content-length: 2334732
    content-type: application/javascript
    date: Sat, 12 Oct 2019 23:36:50 GMT
    expires: Sun, 11 Oct 2020 23:36:50 GMT
    last-modified: Sat, 12 Oct 2019 23:33:24 GMT
    server: nginx/1.16.1
    status: 200

Request Headers:
    :authority: forum.canapin.win
    :method: GET
    :path: /assets/application-301651b1c7400a000974a9cecafd44ad3304cf647cf17bcfa7af68e9ed1ac4b7.js
    :scheme: https
    accept: */*
    accept-encoding: gzip, deflate, br
    accept-language: en-US,en;q=0.9
    cache-control: no-cache
    cookie: _t=89fc0a58f2a08712f3156f2687553cf8; __profilin=p%3Dt%2Ca%3Da546654bdc3538a213cd6c6fcc4c2a92; _forum_session=YnhETkNaTjF1YTEzVXUvZW1pS1NuTVVzdm1WWndlRktMdmNlU3hBalR3dUYwRGVUTzhBSlM5WkNiS0hDdVQvRmtGeGtLOTRRNndRWk9YUFczbTJHdjMyajlNNkpXZ2xzeEZwMkVmd2grcHlILzJVVmZWeFVVNlBERVF4S3VDMkJ0N2pUWktJWitmbXc2MDFFV1VEcG56M09jalRjMEJOb2t6M1NSbjJQUit1eDFRZkdCMGplVjhLK1JUNFVNdnRmVmZuK1B1NVdwK0N5Q1VrNTdDa01tdXh1T3h2aDY4OGx0SDMzRC9Ma0YzdElFS0p6b0x3algvVnRhVlljVDQyOS0tYnpSeFl5MjNoMVFVMm42UE0ybFJ6Zz09--b49c4c072e917618f874818e246298bce81235e5
    dnt: 1
    pragma: no-cache
    referer: https://forum.canapin.win/
    sec-fetch-mode: no-cors
    sec-fetch-site: same-origin
    user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

Haben Sie eine Idee, warum das so ist?

2

Ist Ihre Installation eine Standardinstallation gemäß unserem offiziellen Installationsleitfaden mit Docker?

3

Ich habe mich an diese Anleitung gehalten:
discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

Ich habe lediglich die Ports in der app.yml geändert, bevor ich die App gestartet habe, da der Port 80 bereits belegt war.

Ich habe discourse setup nicht verwendet, da Docker bereits installiert war.

4

Um ganz genau zu beschreiben, wie ich Discourse installiert habe, hier die Schritte, die ich befolgt habe:

git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
cp samples/standalone.yml containers/app.yml

Hier habe ich meine Ports geändert:

## Welche TCP/IP-Ports soll dieser Container exponieren?
## Wenn Sie Discourse einen Port mit einem anderen Webserver wie Apache oder nginx teilen möchten,
## sehen Sie https://meta.discourse.org/t/17247 für Details.
expose:
  - "8080:80" # Host-Port 80 an Container-Port 8080 weiterleiten (HTTP)
  - "4443:443" # Host-Port 443 an Container-Port 4443 weiterleiten (HTTPS)

./launcher bootstrap app
./launcher start app

Und in meiner Nginx-Konfiguration im CentOS Web Panel meinen Port umgeleitet:

image
image1130×802 81.5 KB

Das war’s.

5

Nun, das ist dein Problem: Es wird etwas weitergeleitet, aber nicht ordnungsgemäß durchgereicht.

Ich würde empfehlen, bei unserer Standardinstallation zu bleiben, die das Internet direkt mit unserem Container verbindet und all diese Dinge für dich regelt.

6

Vielen Dank. Ich weiß nicht viel über Server und solche Dinge und ich weiß nicht, wie ich das erreichen kann. Zuvor habe ich Plesk mit den Standardeinstellungen verwendet, und es hat auch mit Nginx-Proxy perfekt funktioniert.

Ich werde es trotzdem versuchen, das herauszufinden, denke ich.

7

Dank @Arkshine wurde mein Problem behoben.

Ich musste diese Zeilen in /etc/nginx/proxy.inc auskommentieren:

proxy_hide_header Vary;

proxy_set_header Accept-Encoding '';

Der Server sendet die Dateien jetzt ordnungsgemäß von Discourse komprimiert:

image
image848×290 29.8 KB