Nejste přihlášeni
- Témata: Aktivní | Nezodpovězená
#1 Re: Ostatní problémy » Vypnutí komprese a použití prostého textu v HTTP odpovědi serveru » 2017-03-07 18:43:46
Problém nalezen a vyřešen! Třeba to někomu pomůže.
1) Odstranění gzip komprimace:
Tím, že se nepošle v požadavku hlavička Accept-Encoding nebude použita gzip komprimace.
Ale, pokud jste v síti za firewallem, ověřte si že tento automaticky nemění vaše HTTP hlavičky ve prospěch komprimace (gzip).
Např. Kerio Control toto dělá defaultně ve svém inspekčním modulu!!!
V takovém případě je nutno na tomto firewallu promapovat port 80 z konkrétního zařízení do internetu.
2) Nastavení odpovědi na prostý text
se provede jednoduše přidáním hlavičky Content-Type: text/plain
3) Odstranění chunked segmentace:
Odpověď serveru musí obsahovat hlavičku Content-Length, tedy délku těla následující odpovědi serveru.
Je tedy nutno nejdříve vytvořit odpověď, aby bylo možno spočítat počet jejích znaků,
jelikož hlavičky odpovědi je nutno bez bufferování odeslat jako první.
Příklad PHP scriptu:
<?php
$text = "#OK#";
header('Content-Type: text/plain');
header('Content-Length: ' . strlen($text));
echo $text;
?>Vrácená odpověď serveru včetně hlaviček:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 Mar 2017 16:41:28 GMT
Content-Type: text/plain
Content-Length: 4
Connection: close
Content-Language: cs
#OK##2 Re: Ostatní problémy » Vypnutí komprese a použití prostého textu v HTTP odpovědi serveru » 2017-03-07 17:15:00
Telnet:
GET /www/headertest.php HTTP/1.1
Host: rynarecka.tode.czOdpověď:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 Mar 2017 12:45:08 GMT
Content-Type: text/html
Xransfer-Encoding: chunked
Connection: close
Content-Language: cs
Content-Encoding: gzip
LN=jéAÝŮa°ČŹIźŰÍ"ĄN=┘Ł─ĐuWwĂĆ$Ľ¸XŽ°ÄÉjôőxĺČŐ ╝?xĂs
<í[żń┤Ź~ÓRHyď├sŐ:~ž▄▀ş_ăŹ5ÄóRŠ8uE&ŹĄÝ<ăÜ]y┤ęÜÝa¸§P:ů\÷{äçďó׹&X8
ň┤mKW[ĐÎ╚s,?É╔ĐZ!"Řݧ¸C┤tĚçŢ'ś!█FxĄ╠nnć§ÇŻňŔ╔ťz╩JóŻŤ#■ ę═ Ř
Připojení k hostiteli bylo ztraceno.Nicméně mám podezření, že závada je na naší straně.
Na firemním firewallu Kerio Control proběhne patrně naprosto automatická a nežádoucí úprava hlavičky a přidána komprimace a proto je vrácena komprimovaná odpověď :-(
Jdu hledat nějaký server v internetu, kde je zapnuto TRACE u HTTP protokolu, abych si ověřil své podezření...
#3 Re: Ostatní problémy » Vypnutí komprese a použití prostého textu v HTTP odpovědi serveru » 2017-03-07 14:59:47
Testuji spojení pomocí telnetu z příkazové řádky a pokud zašlu obyčejný GET požadavek HTTP/1.1 na PHP script, který obsahuje pouze řádek
<?php echo"Headers test"; ?>
i bez udání Accept-Encoding se vrátí v odpovědi tyto hlavičky:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 Mar 2017 12:45:08 GMT
Content-Type: text/html
Xransfer-Encoding: chunked
Connection: close
Content-Language: cs
Content-Encoding: gzip
Abych mohl odpověď zpracovat v jednoduchém jednočipovém mikroprocesoru, chtěl bych odstranit Content-Encoding: gzip a Xransfer-Encoding: chunked.
Zkoušel jsem zavolat v hlavičce i Accept-Encoding: identity, ale bez úspěchu.
#4 Ostatní problémy » Vypnutí komprese a použití prostého textu v HTTP odpovědi serveru » 2017-03-06 23:11:31
- luboss
- Odpovědi: 5
Je možné u jednoho konkrétního PHP scriptu a jeho odpovědi na požadavek klienta nějak vypnout kompresi
Content-Encoding → gzip a Transfer-Encoding → chunked, případně nastavit HTTP na 1.0?
Jde mi o to, jak získat jako odpověď naprosto obyčejný krátký prostý text bez escape sekvencí a netisknutelných znaků v těle odpovědi.
Zaslání požadavku s Accept-Encoding → identity bohužel nemá očekávaný účinek.
#5 Re: Ostatní problémy » Výpadek 24 hodin u Free webhostingu - naprosto bez informací » 2016-10-06 09:42:39
OK, již rozumím.
Datum změny error log souboru nekoresponduje s datumem obsažených záznamů.
Tak to mi nedošlo a omlouvám se.
Z uvedeného logu je patrná chyba na mé straně.
Jenom bych ještě prosil vysvětlit, proč error log z údaji ze dne 4.10.2016
obsahuje pouze jeden ranní záznam ze 7:33 a žádné chyby od 2016-10-04 09:00?
Očekával bych stejné chybové záznamy jako z logu v následující den.
#6 Re: Ostatní problémy » Výpadek 24 hodin u Free webhostingu - naprosto bez informací » 2016-10-06 09:17:53
A proč já vidím své error logy o kterých je řeč a které mě samozřejmě velice zajímají jako prázdné = s nulovou velikostí?
#7 Re: Ostatní problémy » Výpadek 24 hodin u Free webhostingu - naprosto bez informací » 2016-10-05 10:49:03
Na pár vteřin přesně 24 hodin nebylo možné zobrazit ani statické stránky z webu.
Moje informace je získaná z vlastního logu nedostupnosti pro POST požadavky na web + ověřeno opakovanými pokusy o zobrazení webu z PC prohlížečů.
Vždy "stránka nedostupná".
Access.log dosupný u webu končí záznamem s časem 2016-10-04 21-40-37, což jistě není pravda a poslední přístup by měl mít čas 2016-10-05 09:00:05.
Bohužel z dosupných logů webu nejsem schopen odhalit příčinu problémů, protože obsahují jenom starší záznamy.
Např. error.log obsahuje poslední záznam starý 4 dny:
PDOException: SQLSTATE[HY000] [1130] Host 'sasanka.stable.cz' is not allowed to connect to this MySQL
#8 Ostatní problémy » Výpadek 24 hodin u Free webhostingu - naprosto bez informací » 2016-10-05 09:22:22
- luboss
- Odpovědi: 7
Fajn výpadeček Free webhostingu přesně 24 hodin od 2016-10-04 09:00 do 2016-10-05 09:00.
Všechno krásně fungovalo (administrace, FTP,...), jenom web ne, ale bohužel o ten právě jde!
Předpokládám, že tento výpadek s tak krásně zaokrouhleným časem měl nějaký plánovaný důvod
a proto mě opravdu velice moc mrzí, že někdo prostě nenapíše jednu jedninou posra... větu jako informaci že se toto stane (nebo nečekaně stalo)!
Pokud absence informací u Free variant webhostingu má fungovat jako donucovadlo pro přechod na placenou verzi, tak u mě má přesně opačný účinek!
Za mne tedy rozhodně palec dolů. Nikoliv za výpadek, to se nechá u hostingu zdarma pochopit, ale za neinformovanost.
#9 Re: Problémy s MySQL » Překročení kapacity databáze » 2015-12-17 08:21:26
Já mám také dotaz k tématu překročení velikosti MySQL.
Provedl jsem odmazání některých nepotřebných řádků z jedné MySQL tabulky tak, abych se dostal pod požadovanou maximální velikost DB. Toto proběhlo bez problémů, ale následně by bylo třeba provést příkaz 'OPTIMIZE TABLE'. Toto je ale zamítnuto z důvodu nedostatečných práv. Zvolil jsem tedy alternativní postup - export tabulky, její vyprázdnění, počkání na automatické povolení zápisu a teď čekám, kdy budu moci znovu naimportovat redukovaný obsah tabulky. Poradíte mi nějaký elegantnější způsob obejití zamítnutého příkazu OPTIMIZE TABLE při překročení velikostní quóty?
A druhý dotaz - pro správu MySQL používám phpMyAdmin na adrese 'sqla.endora.cz'. Toto rozhraní je ale neuvěřitelně pomalé. To je normální stav, nebo dělám něco špatně?