Http\RequestFactory: added workaround for exceeded post_max_size

[fabik]

http://forum.nette.org/cs/12330-prekroceni-limitrequestbody-pri-nahravani-souboru

[fprochazka]

Chtělo by to nějaký testík :)

[fabik]

Nevíš, jak na to? Ten test by asi musel běžet na webserveru, protože do php://input se zapisovat nedá.

[fprochazka]

Možná by se dal dočasně nahradit protokol php:// za vlastní, pak by to šlo.

A nebo udělat setter, který by nastavoval vstupní cestu, pro účely testování.

private $inputStream = 'php://input';
public function setInputStream($stream)
{
    $this->inputStream = $stream;
}

[fabik]

Tohle funguje.

class StringStream
{
    /** @var string */
    public static $string;

    /** @var int */
    protected $offset = 0;



    public function stream_open()
    {
        return true;
    }



    public function stream_read($length) 
    {
        $buffer = (string) substr(self::$string, $this->offset, $length);
        $this->offset += strlen($buffer);
        return $buffer;
    }
}

stream_wrapper_unregister('php');
stream_wrapper_register('php', 'StringStream');
StringStream::$string = '...';

[lm]

PHP se chová správně když takový request neparsuje, ty data nejsou kompletní, pokud by ten fileinput byl ve formuláři na začátku, tak z toho nepůjdou dostat data žádná.

[fabik]

Testoval jsem to u sebe, fileinput byl první a přesto se data zachránila, zvláštní.

Mám takový pocit, že browser tam ta ostatní data posílá ještě před souborem.

[fabik]

Nevíte někdo, jak nejlépe porovnávat objekty FileUpload?

[fprochazka]

Přidal bych sem na konec, jako prevenci chyb

stream_wrapper_restore('php')

Nette totiž v shutdown funkcích ještě něco zpracovává (byť ne zrovna tohle, ale mohlo by)

[fprochazka]

Assert::equal() by mělo porovnávat pouze hodnoty, ne?

[fabik]

Pravda, to mě nenapadlo.

[fprochazka]

Tohle by ale mohl být problém

http://php.net/manual/en/wrappers.php.php#refsect2-wrappers.php-unknown-unknown-descriptiop

"php://input is not available with enctype="multipart/form-data""

[fabik]

V případě, že velikost requestu překročí LimitRequestBody, tak tam php://input je. (Aspoň mi to takto funguje.)

[fprochazka]

Skoro to vypadá na bug. A navíc by se to k PHP snad nemělo ani dostat - apache, nginx

[fabik]

Aspoň je to užitečnej bug. Možná by se mohlo automaticky přidávat UploadControlům validační pravidlo pro omezení velikosti souboru podle upload_max_filesize, aby to zamítla javascriptová validace. (Což funguje za předpokladu, že administrátor nastaví upload_max_filesize < LimitRequestBody.)

Mohl bys to prosím na nginxu otestovat?

[lm]

Testoval jsem to u sebe, fileinput byl první a přesto se data zachránila, zvláštní.

Zkoušel jsem to a Chrome, IE, FF, Opera zachovala pořadí tak jak bylo ve vygenerovaném HTML, takže file byl před text inputy.

Mohl bys to prosím na nginxu otestovat?

Nginx vrátí rovnou 413 Request entity too large, php to ke zpracování nedá - podle http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody by se měl apache zachovat stejně.

[fabik]

Mně to funguje:
Apache/2.2.22 (Ubuntu)
Chromium 20.0.1132.47 Ubuntu 12.04 (144678): předtím a potom
Firefox 15.0.1 (Ubuntu): předtím a potom

Ale zvláštní je, že když se na to podívám wiresharkem, tak se pořadí zachovává.

[lm]

A jak vlastně v takovém případě vypadá obsah php://input?

[fabik]

Aha, tak už vím, v čem je chyba. Neměl jsem tak nastavený LimitRequestBody, ale jenom post_max_size, vlastně se jedná o defaultní nastavení.

Když nastavím LimitRequestBody, tak mně to vyhodí chybu 413.

[fprochazka]

Takže to můžeme uzavřít? :)

[fabik]

No stále to má jisté uplatnění - v případě, že mám jenom nízký post_max_size, ale nelimituje mě LimitRequestBody (což je defaultní konfigurace), tak to funguje.

[fabik]

Javascriptová validace (ae268bb) je asi lepší, ale zase ji nepodporují všechny prohlížeče. Nejúčinnější by byla asi kombinace obojího.

Ideální by teda bylo dávat do všech UploadControlů další validační pravidlo, které by ověřovalo, že velikost nepřevyšuje upload_max_filesize a do všech Formů pravidlo, že velikost všech dat nepřevyšuje post_max_size.

Ještě by tu mohla být jedna možnost, jak zajistit, aby nedocházelo ke ztrátě dat - uložit všechna pole formuláře někam do cookie nebo html5 storage a při dalším requestu je v případě chyby načíst.

[fprochazka]

To už moc nesouvisí se server-side Nette :)

Ale jinak máš pravdu, že když je nastavena jen jedna direktiva, tak to pomůže a možná by stálo za to, to i podporovat. Jenže tohle je dost nestandardní situace a je to hloupost admina, že něco takového dopustí.

[fabik]

Důležité je, aby uživatel nepřišel o svá data a byl srozumitelně informován o tom, že soubor je moc velký.

Jinak, tohle nastavení mi nepřipadá moc nestandardní. Na všech serverech, co používám, tak to je zrovna takhle - není nastavený LimitRequestBody, ale post_max_size ano. A je to tak i ve standardní konfiguraci apache a php.

[dg]

Tohle je věc, kterou bych ve frameworku rád vyřešil. A ano, důležité je, aby uživatel byl srozumitelně informován o tom, že soubor je moc velký.

Nicméně parsování inputu na straně PHP bych se určitě vyhnul, to je balancování na hraně nedefinovaného chování PHP a prohlížečů. Asi bych to vyřešil jen tím, že by formulář situaci dokázal detekovat a automaticky zobrazit odpovídající chybovou hlášku.

File API na straně JavaScriptu je už dostupné 60 % používaných prohlížečů.(http://caniuse.com/fileapi), mohli bychom tedy validaci pro velikost doplňovat automaticky. Ale není to tak jednoduché (http://php.vrana.cz/velikost-nahravanych-souboru.php) a také je třeba počítat s tím, že uživatel může souborů nahrávat více.

[fabik]

To JavaScriptové řešení vypadá nejrozumněji, nicméně pro těch zbylých 40 % uživatelů je to z hlediska UX docela fail, když sice dostanou srozumitelnou chybovou hlášku, ale přijdou o všechny vyplněné hodnoty. Framework by se mohl alespoň pokusit ta data zachránit.

Sice se v dokumentaci píše, že ten php://input stream není dostupný, ale ve skutečnosti v něm při překročení post_max_size ta data zůstanou (zatím na všech serverech, kde jsem to zkoušel, to tak fungovalo). Myslím si, že když to bude ověřovat přítomnost php://input, tak by v tom neměl být problém.

Pro případ, že by php://input dostupný nebyl, tak by se ještě mělo přidat to ověření do formulářů, aby se aspoň zobrazila ta chybová hláška.