FileResponse – soubor poškozen

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Dismember
Člen | 50
+
0
-

Zdravím,

rozhodl jsem se svou aplikaci pro sdílení souborů nějakým způsobem monitorovat a tak jsem potřeboval, abych před stažením souboru provedl nějaký zápis do databáze, že ten uživatel přistoupil na tento soubor, tohoto zdroje. Šéfové mají rádi čísla, ale to asi víte :)

Takže jsem „hloupý“ odkaz na soubor nahradil signálem

<?php
<a n:href="file! $item->file, $item->source->id, $item->id">{$item->title}</a>
?>

A signál jsem udělal takto:

<?php
public function handleFile($odkaz,$source_id,$item_id){
	$cas = new \DateTime();
	$this->itemRepository->countVisitor($_SERVER['LOGON_USER'],$source_id,$item_id,$cas);

	$fileResponse = new Nette\Application\Responses\FileResponse($odkaz);
	$this->presenter->sendResponse($fileResponse);
}
?>

No tak jsem to trošku otestoval, všechno valilo, logy se plnily. Přijdu po svátcích do práce, vidím hromady přístupů, tak mám radost a najednou na mě lidi řvou, že ten či onen soubor nejde otevřít.

A oni nekecali – některé soubory otevřít lze, některé hlásí poškození, ale po opravě fungují a některé nejdou vůbec, protože jsou prý poškozené

Zkontroloval jsem ty soubory na úložišti a fungují bez potíží. Takže je mi záhadou, kde se stala chyba.

Když opět nabízím soubor pouze pouhým odkazem, tak problém není, ale nic neloguju.

Soubory jsou ruzné formáty – doc, pdf, ppt a různé jazyky – česky, anglicky, rusky…
Funguju na PHP 5.4.23, Nette 2.0.13 a webserver ISS 7.5

Nevíte někdo, jak bych toto mohl vyřešit? Předem díky za pomoc!

petr.pavel
Člen | 535
+
0
-

Adresář s logy je prázdný?

Z toho, co's poskytl nejde nic poznat, takže chyba je nejspíš někde jinde.
Jediné, co mě napadá, je, že LOGON_USER není ve všech případech nastavený a PHP vyhodí nějakou chybu, která se „zobrazí“ na začátku souboru.

Nech si poslat nějaký poškozený soubor a mrkni na začátek, co tam uvidíš.

Dismember
Člen | 50
+
0
-

Díky za reakci.

Logy jsou prázdné, tam se nic neobjevilo.

V souborech, které hlásily, že jsou poškozené se nic nevyskytuje.

Kterou část kódu bych měl poskytnout, aby bylo možné určit, kde může být problém?

Dismember
Člen | 50
+
0
-

Vyzkoušel jsem vypnout to načítání vstupů, abych zjistil, jestli to nemůže dělat ten LOGON_USER

<?php
public function handleFile($odkaz,$source_id,$item_id){
    $cas = new \DateTime();
    //$this->itemRepository->countVisitor($_SERVER['LOGON_USER'],$source_id,$item_id,$cas);

    $fileResponse = new Nette\Application\Responses\FileResponse($odkaz);
    $this->presenter->sendResponse($fileResponse);
}
?>

Nic se nezměnilo. Některé soubory – převážně DOC, DOCX hlásí chybu a jdou otevřít pouze některé a pouze po opravě.

Nemůže být problém s načtením toho typu obsahu (ContentType)? že byla poslána nějak špatně hlavička?

David Matějka
Moderator | 6445
+
0
-

zkousel si ty soubory porovnat nejakym diff nastrojem?

Dismember
Člen | 50
+
0
-

Nezkoušel. Ale zkusil jsem ted diffnow.com

Když ho použiju tak, jak ho stáhnu, tak je obsah nečitelný. Špatná znaková sada. Když ho otevřu ručně, dám opravit a uložím, tak se potom na 100% shoduje s tím originálem.

Nějaké návrhy? :-)

Dismember
Člen | 50
+
0
-

Prosím Vás, nevíte někdo, co s tím mohu dělat?

Mohu si nějak vydumpovat ten request, abych se podíval, jestli se neposílá něco špatně?

Díky za pomoc!

iguana007
Člen | 970
+
0
-

Ahoj,
já jsem řešil hodně podobný problém a u mne bylo řešením vypnutí komprese, která bývá default zapnutá v config.neon
Stačí zakomentovat tento řádek a uvidíš, zda-li ti to pomůže:
# zlib.output_compression: yes

Ono ty soubory vypadají v stejně, když porovnáš originál, který na server nahraješ a ten, který si následně přes ten signál stáhneš, ale ve skutečnosti u toho stahovaného malý kousek dat na konci chybí.

Dismember
Člen | 50
+
0
-

díky za tip, ale tuto kompresi jsem měl taky zakomentovanou.

Takže problém stále nevyřešen :-(

Editoval Dismember (7. 5. 2014 10:32)

iguana007
Člen | 970
+
0
-

Jak toto celé vlákno znovu čtu, tak bych tipoval spíše hledat problém v IIS než v Nette.
Ten kód co si tady ukazoval by měl být správně, takže bych chybu viděl spíše u webového serveru.

Dismember
Člen | 50
+
0
-

No taky mám takové tušení. Jen netuším, jakým způsobem něco takového objevit. Že by tam třeba ISS měl natvrdo nastavené nějaké kódování, které v tom dělá bordel?

Mohl bys mě trochu pošťouchnout, kde hledat? Díky!

iguana007
Člen | 970
+
0
-

No zkusil bych google a microsoft support … namátkou něco je tady:
http://goo.gl/73d5eH
a pak pokračovat tady:
http://goo.gl/60E7gI

Dismember
Člen | 50
+
0
-

Opět se mi děje nějaká duchařina. Mám pro vývoj vytvořenou druhou instanci té aplikace. Je tam stejné php, stejné nette, stejný webserver a pravděpodobně stejná konfigurace…

Na testovacím webu jsem nastavavil ContenType následovně:

<?php
$fileResponse = new Nette\Application\Responses\FileResponse($odkaz,NULL,$contentType = "UTF-8");
?>

A vše funguje správně.

Vložil jsem tedy tuto malou úpravu do ostré verze – a světe div se – ono to nefunguje a soubory stále hlásí poškození…

Rozumíte tomu někdo???

iguana007
Člen | 970
+
0
-

Podle mě pořád hledáš chybu tam, kde není … tj. zkus to řešit v nastavení serveru a ne v aplikaci.

Navíc do content type by si měl předávat spíše něco jako application/pdf … viz.: http://www.w3.org/…nt-Type.html

Dismember
Člen | 50
+
0
-

Včera jsem vyzkoušel další věc – zálohoval jsem si tu testovací aplikaci, která funguje a nahradil ji tou produkční. Abych zjistil, jestli to bude fungovat. (na produkční bylo od doby nasazení provedeno větší množství vývoje než na testovací)

No a zjistil jsem, že ne. Takže v té aplikaci musí být něco nastaveno tak blbě, že nějak kazí funkcionalitu fileresponse. Jenže netuším, kde bych mohl hledat.

Jak si mohu v Chrome nebo IE10 odchytit hlavičku té odpovědi, která mi přijde se souborem? Nemůže být problém tam? Zkoušel jsem tam spusti zachytávání, mnohé věci odchytí, ale stažení souboru tam nejsem schopen najít…