Request Content-Type Header bei Upload

[Jörg Reinholz]

hi Jörg,

Die Erfinder von formData haben also tatsächlich ein bekanntes Fehlverhalten nachgebaut.

Nein. Der Enctype multipart/form-data ist uralt.

Mag sein. Aber irgendwo auf der Strecke Browser -> Apache -> PHP geht das "Multi" vom Multi-Select verloren, wenn man dessen Name nicht die Klammern [] anhängt.

Perl/CGI.pm liefert

Das werde ich mir gleich mal ansehen...

Ja-Nee, war mal wieder klar. Ein simples:

#!/usr/bin/perl  
use CGI qw/:standard/;  
use CGI::Carp 'fatalsToBrowser';  
print "content-type:text/html\n\n";  
print Dump;

liefert, wie hotti schon schrieb, alle Daten zurück, verschluckt sich also nicht wie PHP am Multi-Select.

dann mehrere Dateihandle,

um die geht es jetzt gar nicht. Jedenfalls nicht so richtig.

Ausgangspunkt war lediglich, dass der Chrome behauptete, er dürfe keine Datei senden - aber ich hatte zu dem Zeitpunkt im Formular gar keinen Dateiupload (<file ...>) drin. Den Fehle kann ich noch immer nicht nachvollziehen, ich kann ihn einfach nicht provozieren.

Daneben fällt mir auf, dass formData jedenfalls auch dann einen leeren Eintrag für eine Datei sendet, denn gar keine ausgewählt wurde:

Bei allen anderen Methoden (mein Fußweg, direktes Senden per POST/GET) sieht $_FILES (nach dem Versenden des Formulars mit (jeweils aktuellem) Chromium und Firefox so aus:

$_FILES: Array  
(  
)  

mit formData:

$_FILES: Array  
(  
    [file1] => Array  
        (  
            [name] =>  
            [type] =>  
            [tmp_name] =>  
            [error] => 4  
            [size] => 0  
        )  
  
)  

Das ist auch Mist, weil ich nicht einfach mit einem

if ( isset($_FILES['file1']) ) {  
  ...  
}

in die Prüfung einsteigen kann und dann darin mit

  
if ( $_FILES['file1']['error'] {  
   ...  
}  

prüfen ob ein FEHLER auftrat. Eine gar nicht erst ausgewählte und deshalb nicht gesendete Datei ist kein FEHLER, sondern ein UMSTAND, den ich - mit anderen Methode klappt das, mit if ( isset($_FILES['file1']) ) { ... }  prüfen will.

Aus meiner Sicht ist formData also doch "buggy" - denn wenn ich was nicht gebrauchen kann, dann ist es, dass ich die gesendeten Daten je nach Art des Versandes anders auswerten _muss_. Das bedeutet nämlich, ich muss den "Reaktor" (soll ja schließlich auf gesendete Daten reagieren) nicht allgemein schreiben. Das wieder bedeutet, ich kann nicht ohne weiteres einen "Reaktor" schreiben, der unabhängig davon ist, ob JS angeschaltet oder abgeschaltet ist.

Das mit dem Multi-Select und dem File sind also zwei unabhängige Probleme, die ich lösen muss. Beim Multiselect wird es auf den Vorschlag von United herauslaufen, dem Name des Formularelements immer ein [] anzuhängen umd das richtige Verhalten zu erzwingen. Das ist nicht schön, weil ich das sehr genau merken muss - aber ich kann bei jeder Art des Sendens (XHR [zu Fuß, mit formData], direkt per POST oder GET) bei einer Art bleiben.

$_FILES muss ich also, will ich universell bleiben, mehrstufig auswerten.

Wenn Array leer -> nicht gesendet
wenn Array-Element {name=='' &&  tmp_name=='' && type=='' && error==4 && size==0) -> nicht gesendet.

Was für ein Horror...

Jörg Reinholz