Thread Warum ein Enctype beim Request? (4 answers)
Opened by rosti at 2025-01-11 18:23

rosti
 2025-01-21 11:14
#196834 #196834
User since
2011-03-19
3506 Artikel
BenutzerIn
[Homepage]
user image
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 full thread Warum ein Enctype beim Request?