Audiodatei nach download "kaputt"

bcg · 25. April 2011 um 13:28

Hallo zusammen

folgendes Problem: Ich lade eine Audiodatei (im Test mp3) hoch (via File API / XMLHttpRequest (level 2) (mit xhr.sendAsBinary())). Wenn ich diese dann versuche im Browser abzuspielen (html 5 audio-tag) bzw diese herunterlade, funktioniert das nicht, die Datei sei beschädigt.

Zuerst dachte ich es läge am upload. Wenn ich nun aber die hochgeladene Datei abspiele funktioniert das noch tadellos. Aber nach dem download nicht mehr, wobei die md5-Summe noch die selbe ist.

(Verwende momentan grad Windows, könnts daran liegen? )

Hier der betroffene Code: (der die Datei ausgibt)

//get_info() gibt false oder ein Array wie folgt zurück: [Dateiname, MimeType, DateiID, Datum, Zeit, Grösse, Uploader] if(!($file = get_info($_GET['file']))) header('Location: ./'); header('Content-Type: '.$file[1]); header('Content-Disposition: attachement;filename="'.$file[0].'"'); header('Content-Length: '.filesize('channel/'.$_GET['channel'].'/'.$file[2])); readfile('channel/'.$_GET['channel'].'/'.$file[2]);

chrisb · 25. April 2011 um 13:40

Letzteres klingt irgendwie unwahrscheinlich.

Wie sieht Abspielen direkt „nach dem Hochladen“ aus? (Arbeitest du auf dem lokalen Rechner, wo Client und Server der gleiche sind, und „Abspielen“ bedeutet einfach Doppelklick auf die Datei im Upload-Zielverzeichnis?)

Wie sieht die hoch-und-wieder-runtergeladene Datei im Vergleich zum Original aus, wenn du beide mal in einem Hex-Editor betrachtest? (Den Anfang beider Dateien zu vergleichen, reicht meistens.)

Hat sich da vielleicht eine BOM eingeschlichen, oder zusätzliche Scriptausgaben/Whitespace vor dem eigentlichen Dateininhalt? (Trotz Verwendung von header ohne sichtbare Fehlermeldungen durchaus möglich, wenn output_buffering aktiviert ist.)

Oder stehen vielleicht gar PHP-Fehlermeldungen im Inhalt der Datei drin?

emil · 25. April 2011 um 13:44

hi,
weiß nicht ob das hier ne rolle spielt, aber ist es nicht wichtig, welche dateien man in welchem modus hochlädt?

chrisb · 25. April 2011 um 13:51

Bei FTP ist es wichtig, darauf zu achten - Modus „ASCII“ bedeutet dort, dass die ggf. zwischen den verschiedenen Systemen unterschiedlichen Formate von Zeilenumbrüchen beim Übertragen von Textdateien automatisch „korrigiert“ werden; was man bei Binärdaten, in denen die entsprechenden Bytefolgen aber gar keinen „Zeilenumbruch“ darstellen sollen, natürlich nicht haben will, und deshalb für solche logischerweise den Übertragungsmodus „Binär“ wählt.

Es geht hier aber gar nicht um FTP; und außerdem wird ja schon eine Methode verwendet, die sendAsBinary heißt.

bcg · 25. April 2011 um 13:56

([quote]weiß nicht ob das hier ne rolle spielt, aber ist es nicht wichtig, welche dateien man in welchem modus hochlädt?[/quote]Das hab ich noch ned herausgefunden, jedenfalls mit Text und Zip dateien funktioniert es tadellos und da die md5 summen auch wirklich die selben sind scheints ja auch bei der audiodatei funktioniert zu haben (was sich beweisen lässt, in dem man die hochgeladene datei abspielt)
)

[quote]Letzteres klingt irgendwie unwahrscheinlich[/quote]ja, deshalb hab ichs ja auch geschrieben.

[quote]Wie sieht Abspielen direkt „nach dem Hochladen“ aus? (Arbeitest du auf dem lokalen Rechner, wo Client und Server der gleiche sind, und „Abspielen“ bedeutet einfach Doppelklick auf die Datei im Upload-Zielverzeichnis?)[/quote]jo

[quote]Wie sieht die hoch-und-wieder-runtergeladene Datei im Vergleich zum Original aus, wenn du beide mal in einem Hex-Editor betrachtest? (Den Anfang beider Dateien zu vergleichen, reicht meistens.)[/quote] Habs zwar im notepad vergleicht, aber sieht ziemlich gleich aus. Jedenfalls hab ich die wieder-runtergeladene datei mal umbenennt (urlcodierung entfernt) und das abspielen (per doppelklick) hat wieder funktioniert.

Es hat sich also nix eingeschlichen. Das Abspielen im Browser funktioniert aber nach wie vor nicht. Hier der HTML Code:

[code]

Audiovorschau Dein Browser unterstützt die Audiofunktionen leider nicht [/code]

Danke schon mal

chrisb · 25. April 2011 um 14:27

Dass „funktioniert nicht“ hier in einer der absolut […]sten aller denkbaren möglichen Bedeutungen lediglich ausdrücken sollte, dass du die Datei auf Grund ihres beim Speichern vergebenen Namens nicht per Doppelklick öffnen konntest … na darauf muss man als Antworter, der sich bemüht, aus solchen bescheidenen „Problembeschreibungen“ irgendwelche sinnvollen Informationen zu extrahieren, natürlich auch erst mal kommen. (Auf ein „Tschuldigung, mein Fehler“ wartest du jetzt aber hoffentlich nicht ernsthaft. Dass du bei deinen Problembeschreibungen mal etwas sorgfältiger vorgehen könntest, habe ich dir glaube ich schon ein paar Mal gesagt … Das magst du jetzt vielleicht für „das übliche Gemecker“ halten - aber ziehe auch mal in Betracht, dass die Chancen, dass du ein Problem gelöst bekommst, ganz maßgeblich davon abhängen, wie gut du erst mal dieses Problem beschreiben, definieren und analysieren kannst. Und in der Hinsicht würde ich von dir mit über 1.000 Beiträgen hier langsam echt mal erkennbare Fortschritte erwarten …)

[quote]Das Abspielen im Browser funktioniert aber nach wie vor nicht. Hier der HTML Code:

Dann könnte es sich ggf. auch um eine reines Timing-Problem handeln - falls der Browser versucht, die hier genannte Ressource* bereits anzufordern, bevor die serverseitige Verarbeitung des Uploads überhaupt abgeschlossen ist. Wobei dann der von diesem Script ausgegebene „Stream“ entweder ganz „hängen“, oder aber tatsächlich im Datenteil PHP-Fehlermeldungen a la “Datei nicht gefunden” enthalten dürfte. Das mal zu analysieren, in dem du dir die HTTP-Datenübertragung bspw. im Net-Panel von Firebug anschaust, auf diese eigentlich naheligende Idee bist du nicht gekommen …?

(Ob das hier tatsächlich der Fall und damit die Ursache des Problems ist, auch das lässt sich auf Basis einer wenig durchdachten „funzt nich, hier ein paar Schnippsel Code: […]“-Problembescheibung natürlich kaum zweifelsfrei sagen. Also untersuche es jetzt bitte mal.)

Edit: Dass die Adresse korrekt ist, hast du hoffentlich erst mal sichergestellt? Ich frage nur, weil bei get?file=… vielleicht auch einfach nur die Dateiendung des Scriptnamens fehlen könnte …

bcg · 25. April 2011 um 21:47

ja das mit der Problembeschreibung tut mir leid.

[quote][…]dass du die Datei auf Grund ihres beim Speichern vergebenen Namens nicht per Doppelklick öffnen konntest … na darauf muss man als Antworter, der sich bemüht, aus solchen bescheidenen „Problembeschreibungen“ irgendwelche sinnvollen Informationen zu extrahieren, natürlich auch erst mal kommen.[/quote] ja, tut mir leid. Mir wären ja selbst fast die augen rausgefallen als das dann plötzlich wieder funktioniert hat, da mal ab und zu (ziemlich immer wenn in meinem abspielprogramm eine audiodatei keinen titel hat und abstände enthält in der titelleiste des Programms solche urlcodierten Zeichenketten stehen.
Selbstverständlich erwarte ich kein „oh sorry mein fehler“ von dir - ist ja offensichtlich nicht dein fehler (ich hoffe mal darauf bist du selber gekommen [- wenn ich auch so wie du schreiben darf]).

Ich les ja öfters beiträge mit schlechten problembeschreibungen und auch entsprechende Antworten darauf… also nochmals es tut mir echt leid

ich hoff nur jetzt hilft mir noch einer

–

[quote]Dann könnte es sich ggf. auch um eine reines Timing-Problem handeln - falls der Browser versucht, die hier genannte Ressource* bereits anzufordern, bevor die serverseitige Verarbeitung des Uploads überhaupt abgeschlossen ist.[/quote]Das kann nicht passieren, nein, da der link zur vorschau erst angezeigt wird, wenn die übertragung tatsächlich abgeschlossen ist.

Die Adresse ist selbstverständlich korrekt. - Scheinbar wird auch der richtige code aufgerufen, wie ich den Headern entnehmen kann.

[quote]Wobei dann der von diesem Script ausgegebene „Stream“ entweder ganz „hängen“, oder aber tatsächlich im Datenteil PHP-Fehlermeldungen a la „Datei nicht gefunden“ enthalten dürfte.[/quote]Nein weder noch. Firebug sagt mir, dass der Antwortbody 786 KB gross sei, zeigt ihn mir jedoch nicht an (Im Header steht allerdings content-length: 2717283, was etwas mehr als 2.6 MB sein dürften, wie gross die Datei auch tatsächlich ist - und soviel gibt php auch aus (sagt zumindest readfile)) könnte es am mimetype liegen, dass firebug aufs anzeigen verzichtet?. - wenn ich nun aber die betreffende Adresse „kopiere“ und manuell aufrufe kommt der download dialog - ich mach öffnen mit und die datei wird scheinbar unbeschädigt abgespielt.
Bei ner deutlich kleineren Datei zeigt er mir beim antwort body die richtige grösse an (59KB) das Abspielen funktioniert jedoch immer noch nicht.

[quote]im Net-Panel von Firebug anschaust, auf diese eigentlich naheligende Idee bist du nicht gekommen …?[/quote]nein, tut mir leid (ergebnisse siehe ein paar zeilen weiter oben)

[quote]Ob das hier tatsächlich der Fall und damit die Ursache des Problems ist, auch das lässt sich auf Basis einer wenig durchdachten „funzt nich, hier ein paar Schnippsel Code: […]“-Problembescheibung natürlich kaum zweifelsfrei sagen.[/quote]ja, hab mir wirklich nix dabei gedacht hier im forum zu fragen wenn ich slebst nich auf die lösung komm’ is es gefälligts mein eigenes problem.
Naja, ich dachte eben das problem „falsche uri“ und „falscher dateiinhalt“ sei geklärt - aber nächstes mal werd ich auch das schreiben, wenn ich das eigenhändig ausgeschlossen hab (ich kann ja nich wissen das mir das nach meinen 1000 posts immer noch nich zugetraut wird (wie ich gerade bewiesen habe bin ich tatsächlich in der lage das zu tun) - und ich hoff das hast du nicht hinstellen wollen: „jetzt hast du schon 1000 frage-posts gestellt und immernoch bist n noob“) - b2t: wenn eben der inhalt der datei richtig zu sein scheint (was er ja beinahe MUSS, wenn für den download und das abspielen im browser ein und die selbe URI verwendet werden) an was könnte es denn dann liegen? kann ja durchaus sein, dass ich vollidiot zu dumm für den html5-autio tag (kann ich ja nicht wissen, anscheinend funktioniert ja die erste anwendung dieses tag tatsächlich nicht)

[quote]Ich frage nur, weil bei get?file=… vielleicht auch einfach nur die Dateiendung des Scriptnamens fehlen könnte …[/quote]tatsächlich - da ich nun ma get schöner finde als get.php und eh die betroffene uri umschreiben musste hab ich echt die dateiendung weg gelassen - tut mir leid nächstes mal schick ich die .htaccess auch noch mit)
Aber langsam hab ich das gefühl dass dann mein hilfeschrei eifach zu umfangreich wird und ihn niemand mehr liest ? Na ich könnt auch gleich das ganze projekt als zip hochladen dass es jeder von euch sich installieren kann und ich in den ganzen code einlesen kann, falls er lust dazu hat.

na dann, gute nacht

chrisb · 25. April 2011 um 22:49

“Don’t Panic!”

Lass mich das mit einem Stück Code beantworten:

class Wald { private $text; public function hineinrufen($wie) { $this->text = $wie; } public function herausschallen() { return $this->text; } }

(Auf Deutsch - ja, das kann ich ab.)

Dass Firebug dir den Request Body nicht anzeigen will, muss nichts heißen - Text-Daten zeigt er normalerweise an, Bilddaten stellt er auch direkt dar - aber Audiodaten lassen sich so schlecht visuell darstellen, deshalb verzichtet er in diesem Fall vielleicht einfach darauf, dich das Binär-Gibberish anschauen zu lassen. (Gerade mal getestet, mit einer über einen Flash-Player geladenen mp3-Datei - nein, da will Firebug mich auch keinen Request-Body anschauen lassen, abspielen funktioniert aber.)

786 KB sind natürlich „zu groß“ für ein paar PHP-Fehlermeldungen, aber eben auch zu klein für eine 2,6 MB große mp3-Datei.

Woraus sich diese Diskrepanz ergibt, sollten wir mal untersuchen.

Das sagt dir readfile wo und wie in diesem Umfeld?

Welchen Content-Type-Header bekommt der Browser denn laut Firebug vom Server ausgegeben?

(Wenn die Angabe ganz fehlt, oder falsch ist, kann’s daran natürlich liegen, denn in der Hinsicht sind moderne Browser pingelig [kenn ich nicht, fress ich nicht] - und das ist auch gut so, denn dass man z.B. alten IEs JavaScript-Code durchaus auch als vermeintliches „Bild“ unterschieben konnte, gehört ja zu den legendären WTF?-Sicherheitslücken.)

Das können wir ja leicht ausschließen bzw. verifizieren, in dem du mal eine „normale“ mp3-Datei, die du nicht über dein Script hochgeladen hast und auch nicht über dein PHP-Script wieder ausgeben lässt, sondern ganz normal über Angabe der Adresse in der Form „lalelu.mp3“ vom Webserver ausliefern lässt, testest - wird die abgespielt, wenn du sie per AUDIO-Element einbindest?

Wenn’s das irgendwo online zu betrachten gibt, wäre mir lieber - dann kann ich’s erst mal „von außen“ zu analysieren versuchen. (Ggf. Adresse auch per PN, wenn du es nicht öffentlich hier reinstellen willst.)

progandy · 25. April 2011 um 23:05

Das hat jetzt nichts mit dem Problem zu tun, aber header(‘Location: ./’); ist nicht wirklich sauber. ein die() sollte besser sein.

hoffmann · 26. April 2011 um 08:51

Noch eine wilde Hypothese:
Vor Jahren habe ich bei einer damals aktuellen Version von PHP
mal beobachten müssen, daß PHP offenbar auch per readfile
eingebundenen Dateien untersucht und gegebenenfalls manipuliert.
In meinem Falle hat das Teil versucht, in der Datei URIs zu ändern,
session-Daten anzuhängen. Wenn du also sessions verwendest,
kann es durchaus sein, daß PHP immer noch ‘readfile’ vergurkt ;o)

Wenn die md5-Summe vor dem Heraufladen und nach dem
Herunterladen allerdings dieselbe ist, ist eine Manipulation der
Datei ziemlich auszuschließen. Bleibt dann z.B. noch der genannte
Inhaltstyp (MIME), der mit der md5-Summe nichts zu tun hat, aber
wichtig für eine Interpretation ist.

Testweise kann man die Datei ja auch mal ohne Tricks und PHP
direkt mit dem browser über HTTP aufrufen, um zu gucken, ob mit
Datei oder Inhaltstyp was falsch ist (Hinweis nur, weil ich nicht
genau durchschaut habe, wann die Datei bei dir wirklich genau
funktioniert und wann nicht - mag sein, daß du das schon überprüft
hast).

chrisb · 26. April 2011 um 11:35

[quote=“hoffmann”]Vor Jahren habe ich bei einer damals aktuellen Version von PHP
mal beobachten müssen, daß PHP offenbar auch per readfile
eingebundenen Dateien untersucht und gegebenenfalls manipuliert.
In meinem Falle hat das Teil versucht, in der Datei URIs zu ändern,
session-Daten anzuhängen.[/quote]
Daran ist nichts besonders ungewöhnlich.

Per readfile gelesene Daten landen im Output-Buffer - und wenn session.use_trans_sid aktiviert ist, dann wird am Scriptende nach relativen Adressen innerhalb des Pufferinhaltes gesucht, an die die SID angehängt wird.

Works as designed würde ich das nennen.

hoffmann · 26. April 2011 um 11:53

Das mag schon sein, nur wenn man das bräuchte, hätte man den
Kram per include oder ähnlichem geladen, insofern also ein
konzeptioneller Fehler, der zudem den Durchsatz verlangsamt, etwa
wenn man damit Bilder, Audio oder Video durchschleift, wie hier
beabsichtigt. Vermutlich möchten es deswegen auch einige Anbieter
von webspace nicht, daß man Bilder etc durch PHP durchschleift,
weil readfile schlecht umgesetzt ist.

chrisb · 26. April 2011 um 12:11

Nein, wieso?
Wie du deinen Daten zusammenstellst, sollte dem Session-Mechanismus vollkommen egal sein dürfen.

Ja - einer des Scripterstellers, der Sessions bzw. das von denen ausgelöste URL-Rewriting nicht explizit abgeschaltet hat in dem Fall, wo er es nicht braucht bzw. nicht haben will

hoffmann · 26. April 2011 um 13:42

[quote=“chrisb”]
Ja - einer des Scripterstellers, der Sessions bzw. das von denen ausgelöste URL-Rewriting nicht explizit abgeschaltet hat in dem Fall, wo er es nicht braucht bzw. nicht haben will ;-)[/quote]

Hat ja vermutlich wenig mit dem hiesigen Problem zu tun, aber
bei meinem Falle diente die session und das PHP-Skript
gerade dazu, um zu kontrollieren, von wo aus auf die
herunterzuladende Datei zugegriffen wird, nicht um die
herunterzuladende Datei zu manipulieren, die sollte einfach nur
ausgegeben werden, nachdem der Zugriff als berechtigt
festgestellt wurde - wie immer der browser die session auch
übermittelt hat.
Vermutlich kann man das schon so drehen, daß man die session
kontrollieren kann (unabhängig davon, woher die session-Daten
kommen), ohne den Inhalt zu korrumpieren, aber für mich sagt
schon der Name ‘readfile’, daß die Datei ausgelesen wird, nicht
modifiziert.
Ich habe das Problem dann in der Tat so umgangen, daß ich
den session-Kram komplett deaktiviert habe und eine eigene
Kontrollvariable eingeführt und dort angehängt habe, wo es
wirklich sinnvoll war. Insofern habe ich das Problem in der Tat
etwa so wie vorgeschlagen umgangen, was aber nicht besonders
effektiv ist, weil PHP die Funktion ja eigentlich selbst anbietet, die
ich hätte brauchen können, wenn davon readfile nicht betroffen
wäre.

Insofern hat es vielleicht doch was mit dem hiesigen Problem
zu tun - PHP kann Dateien manipulieren, die mit readfile
eingelesen werden, also muß man genau prüfen, was das Teil
da warum dran herumfingert und notfalls eben das eigene
Konzept so ändern, um zu vermeiden, daß PHP die Datei
korrumpiert - mag das Korrumpieren nun Absicht der PHP-Autoren
sein oder nicht - und das Effektivitätsproblem bei so
durchgeschliffenen Dateien bleibt natürlich bei PHP - oder ist da
eine Methode bekannt, wie man eine Datei wirklich ohne
Interpretation durch PHP durchbekommt, egal was da wie
für das PHP-Skript eingestellt ist, was den Kram dann ausgeben soll.
Wenn PHP dafür eine andere Funktion hat, könnte das ja
vielleicht auch hier helfen, dem Fehler auf die Spur zu kommen,
wenn es statt readfile verwendet wird, um die Fehlerquelle
auszuschließen.

progandy · 26. April 2011 um 14:05

Du solltest du sicherstellen, dass session.use_trans_sid deaktiviert ist. Auch irgendwelche ob_-Handler solltest du deaktivieren wenn du Dateien sendest. Dann werden die Dateien ohne Veränderung von PHP an den Webserver weitergereicht. (Apache könnte hier z.B. noch einen gzhandler zwischenschalten, das ist zumindest bei bplaced so). Der Webserver sendet die Datei dann zum Browser.

chrisb · 26. April 2011 um 14:18

Ja - session.use_trans_sid deaktivieren, fertig.

[quote]aber für mich sagt schon der Name ‘readfile’, daß die Datei ausgelesen wird, nicht
modifiziert.[/quote]
Die Funktionsbeschreibung lautet “Reads a file and writes it to the output buffer.”

Dass man sich der Wechselwirkung, die das ggf. in Kombination mit aktiviertem URL-Umschreiben durch den Session-Mechanismus hat, nicht bewusst ist, kann passieren - ist aber m.E. nicht PHPs Schuld.

Und ohne unvorhergesehene Probleme, die man analysieren muss und dabei was neues lernen kann, wäre es doch auch langweilig

Dann hättest du sie explizit deaktiviert für genau diesen Spezialfall, wo du sie nicht haben willst (und im restlichen System nach wie vor genutzt) - und gut wäre gewesen …
Btw., Default für session.use_trans_sid ist inzwischen 0, also off.

Die Kontrolle der md5-Checksumme scheint ja dagegen zu sprechen. (In der Theorie natürlich noch denkbar, dass zwischen Abspeichern und „Streaming“ das Script immer noch unterschiedliches Verhalten produziert - bezweifle ich nach derzeitiger Faktenlage aber.)

hoffmann · 26. April 2011 um 15:25

Das war die Variante, die auf meinem lokalen server auch
funktionierte - aber wie eingangs erwähnt, das Problem ist vor
Jahren aufgetreten, da gab es bplaced noch gar nicht und bei dem
damaligen Anbieter waren Funktionen gesperrt, mit denen man die
Konfiguration von PHP hätte beeinflussen können, insofern also
doppelt spannend, solche Tücken zu umgehen ;o)

[quote=“chrisb”]
Die Kontrolle der md5-Checksumme scheint ja dagegen zu sprechen. (In der Theorie natürlich noch denkbar, dass zwischen Abspeichern und „Streaming“ das Script immer noch unterschiedliches Verhalten produziert - bezweifle ich nach derzeitiger Faktenlage aber.)[/quote]
Jaja, man muß genau gucken, was man womit vergleicht, um sich
nicht selber reinzulegen. Wenn wir mal davon ausgehen, daß
das nicht der Fall ist, so läßt die Existenz des Problems immer noch
vermuten, daß es dafür auch eine Ursache gibt, die man irgendwie
aus dem Trüben fischen muß ;o)
Wenn der Inhalt der gleiche/selbe ist, der Inhaltstyp paßt und das
Problem mit verschiedenen browsern immer reproduzierbar ist,
sollte beim Fischen im Trüben eigentlich zügig was bei
herauskommen…

bcg · 26. April 2011 um 16:33

echt - meine worte -.-

while(hat_fehler($projekt)) { nochmal_nachlesen_in_dokumentation_zu($projekt->dokumente); weiter_programmieren($projekt) } //!! da steht nix von "im_forum_fragen()"!!
ich glaub des schreib ich mir (mit nem ganz ganz fetten filzstift) aufn bildschirm -.-

[quote=„chrisb“]Das können wir ja leicht ausschließen bzw. verifizieren, in dem du mal eine „normale“ mp3-Datei, die du nicht über dein Script hochgeladen hast und auch nicht über dein PHP-Script wieder ausgeben lässt, sondern ganz normal über Angabe der Adresse in der Form „lalelu.mp3“ vom Webserver ausliefern lässt, testest - wird die abgespielt, wenn du sie per AUDIO-Element einbindest?[/quote]Ich weis nich ob ich jemals auf die idee gekommen wäre, dass ich ja selber gelesen hab dass der ff mp3s nicht spielt -.- autsch autsch autsch

Tut mir wirklich leid (ich dummkopf ) - is ja wirklich ned unbrauchbare problembeschreibung
Danke viel mal für eure Diskussion (ohne wär ich ja schliesslich nie auf die lösung gekommen)

Ich hoff ich werd nie wieder wegen so nem blöden furz son thread posten (geschweige denn eine solche diskussion anregen)

Trotzdem würd ich noch gerne der einen sache nachgehen:

[quote]786 KB sind natürlich „zu groß“ für ein paar PHP-Fehlermeldungen, aber eben auch zu klein für eine 2,6 MB große mp3-Datei.[/quote]Wobei ja in beiden fällen (download und „stream“ im browser) die selbe URI aufgerufen wird… (firebugbug )

[size=85]Ach, noch kurz zum thema Mime-Type:
Da ich den mime type ausliefere, den mir der browser beim upload mitgeliefert hat, sollte das kein problem werden können (was es ja auch ned is)[/size]