Weitere Infos:
Enctype application/x-www-form-urlencoded
Das ist der Default. D.h., er muss nicht angegben werden. Was in einem <form>-Element der Enctype ist, das ist bei einem POST auch gleichzeitig der Content-Type.
Wenn also notiert wurde <form method="POST" Enctype="application/x-www-form-urlencoded">
wird bei einem Submit aus dem Enctype-Attribute der Request-Header Content-Type. Wurde dieses <form>-Attribute nicht angegeben, wird ein Content-Type-Request-Header gar nicht gesendet. Genau das ist ja der Sinn eines Default.
Von daher werden wohl die Wenigsten diesen Enctype jemals in Formularen notiert haben. Des Weiteren ist ein Request-Header Content-Type nicht einmal dann notwendig, wenn es einen Message-Body gibt. Jedoch ist in diesem Fall ein Request-Header Content-Lenght erforderlich welcher die Länge des gesendeten Messagebody angibt (Anzahl der Bytes).
Ob serverseitig ein body in STDIN zu erwarten ist, macht der Server am Requestheader Content-Length fest und nicht etwa an der Requestmethode. Letztere kann ein Client ja auch ZITRONE
genannt haben, und ja, mit fetch() ist das auch möglich.
Der Content-Type schließlich teilt dem Serverprozess mit, wie die Daten wiederherzustellen sind.
Was jQuery(form).serialize() betrifft: Da gibt es mit native JS derzeit keine Alternative. Wer sich da selbst was zusammenbauen möchte, sollte zumindest wissen wie der Default Enctype aufgebaut ist und dass man diesen nicht nur an einen URL anhängen sondern auch als MessageBody senden kann.
MfG