| Autor | Zpráva | ||
|---|---|---|---|
| blaaablaaa Profil |
Na webu mám kvůli úspoře místa na disku uložené soubory (konkrétně gpx trasy) zkomprimované (gzip).
Když je odesílám klientovi, zjistím, zda podporuje gzip a pokud ano, pošlu mu přímo obsah souboru s hlavičkou Content-Encoding: gzip, pokud ne, rozbalím soubor a pošlu ho rozbalený.
Problém je, že mám zároveň nastaveno AddOutputFilterByType DEFLATE application/gpx+xml, v takovou chvíli mi některé instance chromu (asi i další prohlížeče) soubor nedokáží dekódovat a vyhodí "ERR_CONTENT_DECODING_FAILED 200" (tipuju, že se soubor zkomprimovaný gzipem zkomprimuje znovu zkomprimuje přes deflate a prohlížeč to nerozdýchá).
Dá se serveru nějak říct, aby deflate filtr nepoužíval, pokud už je nastavena hlavička Content-Encoding? Případně jak toto lépe řešit? Vykuchany fragment php: header('Content-type: application/gpx+xml');
if ( strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== false ) {
header('Content-Encoding: gzip');
readfile('zagzipovany.gpx.gzip');
} else {
echo gzuncompress(file_get_contents('zagzipovany.gpx.gzip'));
}.htaccess: <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE application/gpx+xml </IfModule> |
||
| Kajman Profil |
#2 · Zasláno: 9. 9. 2020, 10:09:31
Zkus před první řádek dát ještě
apache_setenv('no-gzip', '1'); |
||
| blaaablaaa Profil |
#3 · Zasláno: 9. 9. 2020, 11:22:27
Kajman:
Díky, zapomněl jsem dodat, že server běží na nginxu (managed vps na Savaně), htaccess tam je nejspíš přes nějakou extensionu (?). |
||
| Kajman Profil |
#4 · Zasláno: 9. 9. 2020, 12:07:41
Pokud ten php skript neřeší přístupová práva, tak možná půjde nginx jen nastavit, že v té složce jsou zagzipované soubory a když potřebuje, že je rozbalí.
docs.nginx.com/nginx/admin-guide/web-server/compression |
||
| blaaablaaa Profil |
#5 · Zasláno: 9. 9. 2020, 12:18:38
Kajman:
Ten skript právě řeší přístupová práva :( Každopádně ani úprava konfigurace by nebyla možná, na savaně nemám root práva, takže nginx.conf nezměním. Předpokládám tedy, že pokud nechci server a uživatele zatěžovat neustálou dekomprimaci, nezbude než mít soubory uložené nezabalené. |
||
| Kajman Profil |
Zkus si logovat, kolikrát prohlížeč tvrdí, že nepodporuje gzip. Možná nebudeš mít ani jeden takový záznam.
Spíš je divné to dvojité gzipování. Když už se pošle hlavička Content-Encoding, tak by to nginx měl nechat být. Zkus se podívat na http hlavičky při tom chybném požadavku. Odpověď si uložit do souboru a zkusit ji 2x rozbalit, zda to je opravdu 2x zabalené, nebo naopak zda to není rozbalené a hlavička tvrdí, že to je zabalené. |
||
| blaaablaaa Profil |
#7 · Zasláno: 9. 9. 2020, 13:03:23
Kajman:
Díky, zkusím nějakou dobu logovat a pořádně ověřit, co přichází/vracím a uvidíme. Dám pak vědět. |
||
| Davex Profil |
#8 · Zasláno: 9. 9. 2020, 19:21:30
blaaablaaa:
„server běží na nginxu (managed vps na Savaně), htaccess tam je nejspíš přes nějakou extensionu (?)“ Nginx používá jinou syntaxi konfigurace a soubory .htaccess nečte, takže pokud tam není nějaký převaděč, tak s největší pravděpodobností se to nastavení v .htaccess vůbec neaplikuje a problém může být někde jinde. Například pokud by byly soubory zkomprimované v PHP funkcí gzcompress, tak výsledkem budou holá data bez hlavičky formátu gzip a prohlížeče s tím můžou mít problém. Osobně bych pro tento účel použil gzencode/gzdecode.
|
||
| N71 Profil * |
#9 · Zasláno: 10. 9. 2020, 12:16:19
Gzip komprese je podporována takřka všemi prohlížeči. Situace, že by klient nerozuměl datům s hlavičkou Content-Encoding: gzip, je už třeba takových deset let prakticky vyloučena.
|
||
| blaaablaaa Profil |
Tak tedy hlavičky, které přichází/odchází, když chrome vyhodí chybu:
Požadavek (promazáno):
[REDIRECT_HTTPS] => on
[REDIRECT_STATUS] => 200
[HTTP_CONNECTION] => close
[HTTP_UPGRADE_INSECURE_REQUESTS] => 1
[HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
[HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
[HTTP_SEC_FETCH_SITE] => cross-site
[HTTP_SEC_FETCH_MODE] => navigate
[HTTP_SEC_FETCH_DEST] => document
[HTTP_ACCEPT_ENCODING] => gzip, deflate, br
[HTTP_ACCEPT_LANGUAGE] => cs-CZ,cs;q=0.9,en;q=0.8,sk;q=0.7
[REDIRECT_URL] => /files/gpx/1827.gpx
[GATEWAY_INTERFACE] => CGI/1.1
[SERVER_PROTOCOL] => HTTP/1.1
[REQUEST_METHOD] => GET Odpověď: [0] => Expires: Thu, 19 Nov 1981 08:52:00 GMT
[1] => Cache-Control: no-store, no-cache, must-revalidate
[2] => Pragma: no-cache
[3] => x-frame-options: sameorigin
[4] => Content-type: application/gpx+xml
[5] => Content-Encoding: gzip+ v těle jde text prohnaný přes gzcompress($str, 9)
|
||
| Kajman Profil |
#11 · Zasláno: 10. 9. 2020, 13:17:46
Tak zkus soubory na disku přebalit pomocí toho gzencode, jak psal Davex.
|
||
| blaaablaaa Profil |
Kajman:
Tak problém má i validátor :( GPX: www.vrcholovka.cz/files/gpx/1827.gpx?test Validátor: validator.w3.org/check?uri=https%3A%2F%2Fwww.vrcholovka.cz%2Ffiles%2Fgpx%2F1827.gpx%3Ftest&charset=%28detect+automatically%29&doctype=Inline&group=0 Aktuálně je tam (kromě hlaviček): $data = gzuncompress(file_get_contents($path_to_gzipped)); echo gzencode($data); |
||
| blaaablaaa Profil |
#13 · Zasláno: 11. 9. 2020, 09:38:10
Tak validátor měl soubor nejspíš nacachovaný (?) a včera ještě zobrazoval chybu, protože dnes už to s gzencode jde. Problém byl tedy v použití gzcompress. Díky všem, především Davex.
|
||
|
Časová prodleva: 4 roky
|
|||
0