Warum ein Enctype beim Request? (Webframeworks, Sonstige Fragen zur Webprogrammierung mit Perl)

[thread]21647[/thread]

Warum ein Enctype beim Request?

Tags: perl5 Ähnliche Threads

Leser: 6

Articles: hide open all | hide show old branches

+5 replies
rosti

2025-01-11 18:23

User since
2011-03-19
3506 Artikel
BenutzerIn

Was im Browser als Enctype angegeben wird, ist der Content-Type des gesendeten HTTP-Message-Body. In der Regel ist es jedoch so, daß der Programmierer der Webanwendung festlegt, was mit diesem Body gemacht werden soll.

Also wenn der HTML-Designer notiert Enctype="multipart/form-data" dann ist das eigentlich überflüssig, denn der Auftrag an die webseitige Programmierer beeinhaltet ohnehin die Verarbeitung eines Dateiuploads und was mit den einzelnen Dateien gemacht werden soll.

Ebenso dürfte es bereits zum Zeitpunkt der Entwicklung feststehen, wenn im Message-Body ein JSON-String erwartet wird und was es damit auf sich hat. Und in den seltensten Fällen, die es vielleicht geben mag, wird sich ein CGI-Entwickler auf das verlassen, was ein User-Agent als Enctype bzw. Content-Type dem Request mitgibt.

Wenn ich diesem POST hier, der mit dem Enctype multipart/form-data rausgeht, einen anderen Enctype unterschiebe, geht das Absenden mit ziemlicher Sicherheit in die Hose anstatt in die Datenbank.

Was meint Ihr dazu?
Last edited: 2025-01-11 18:24:45 +0100 (CET)
- +2 replies
- haj
  
  2025-01-11 19:19
  
  User since
  2015-01-07
  561 Artikel
  BenutzerIn
  
  Der enctype sagt dem Browser, wie er die Formularfelder in einen Request übersetzen soll, die Voreinstellung ist application/x-www-form-urlencoded. Der Browser könnte, wenn er ein Feld mit type=file im Formular vorfindet, automagisch auf multipart/form-data umschalten... aber dann würde die Beschreibung im Standard verschwurbelter, weil der Default-Wert eines Attributs im form-Element von einem Attribut eines input-Elements anhängig wäre.
  - rosti
    
    2025-01-11 22:12
    
    User since
    2011-03-19
    3506 Artikel
    BenutzerIn
    
    Interessanter Gedanke!
    
    PS: Mit dem FormData-Objekt (JavaScript) passiert das automatisch, also daß der Enctype auf multipart/form-data gesetzt wird. Und wenn einer der Parts ein Blob-Objekt ist, wird das quasi als ein input type="file" interpretiert und der Parameter filename gesetzt. In PHP landet damit dieser Part im Upload-Array (simuliertes Upload).
    Last edited: 2025-01-12 11:06:17 +0100 (CET)
- rosti
  
  2025-01-12 14:42
  
  User since
  2011-03-19
  3506 Artikel
  BenutzerIn
  
  Quote
  Was im Browser als Enctype angegeben wird, ist der Content-Type des gesendeten HTTP-Message-Body. In der Regel ist es jedoch so, daß der Programmierer der Webanwendung festlegt, was mit diesem Body gemacht werden soll.
  
  Das gilt auch für AJAX. Da ist es sogar so, daß der Programmierer bereits beim Request festlegen kann, welcher Content-Type (responseType) in der Response erwartet wird und zwar unabhängig vom in der Response tatsächlich gesendeteten Content-Type. Wobei man diesen freilich auch prüfen kann aber i.d.R. ist der gesendetet Content-Type völlig Wurst.
- rosti
  
  2025-01-21 11:14
  User since
  2011-03-19
  3506 Artikel
  BenutzerIn
  Um die Sache mal ein bischen interessanter zu machen: Vor etwa 10 Jahren habe ich mir überlegt, was zu tun ist um bestimmte Parameter namentlich in jedem Falle abfragen zu können. Also daß ein $self->param('foo') dasselbe Ergebnis liefert wenn der Sender den Content-Type von application/x-www-form-urlencoded auf application/json ändert und natürlich auch einen solchen Content sendet.
  
  Die Antwort auf diese Frage läuft daraus hinaus, daß man hierzu die zu nutzenden Daten mit Schlüsselparametern mischt, also alles zusammen im Payload, dem bei einem POST gesendetem HTTP-Message-Body unterbringt. Und zwar so, daß ein $self->param('foo') eine Datenstruktur vorfindet wo der Parameter 'foo' auch gefunden wird. Und das ist schlecht. Denn was wäre, wenn Parameter 'foo' zum Payload gehört?
  
  So kann die Antwort nur lauten, Nutzdaten von Schlüsselparametern strikt zu trennen. Was ganz einfach möglich ist dadurch daß die Schlüsselparameter über den Query-String kommen, die Nutzdaten hingegen mit dem Message-Body. Und siehe da, für den Query-String ist der Content-Type gar nicht zuständig.
  
  Ergo liefert $self->param('foo') stets 'bar' wenn im Query-String foo=bar gesendet wird, egal ob das Payload als application/pdf oder application/json ankommt. Nur der Entwickler weiß was mit dem Paylod zu tun ist. Und auch das lässt sich sodann in einer Kontrollstruktur unterbringen, etwa so:
  
  Code (perl): (dl )
  
  1 2 3
  
  if( $self->param('csv') ){...} elsif( $self->param('json') ){...} else{...}
  
  Was also vollkommen unabhängig davon ist, welchen Enctype der UserAgent vorgibt.
  
  PS: Und da Schlüsselparameter nur einmal vorkommen, erübrigt sich da auch die Frage nach mehreren gleichnamigen Parametern like name=foo;name=bar;name=fips
  Last edited: 2025-01-21 13:55:31 +0100 (CET)

View all threads created 2025-01-11 18:23.