> Luckily the W3C deities gave us exactly such a gift in the form (pun intended) of the enctype attribute. Minor quibble: enctype="text/plain" didn’t come from

> Luckily the W3C deities gave us exactly such a gift in the form (pun intended) of the enctype attribute. Minor quibble: enctype="text/plain" didn’t come from W3C. HTML 4.0 forms only defines enctype="application/x-www-form-urlencoded" (which pct-encodes the json delimiters {"":}) and enctype="multipart/form-data" (which has a non-json Boundary prefix) so if those were the only enctypes that browsers used, then this exploit would not have worked. https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 WHATWG HTML5 does define enctype="text/plain" behavior https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#form-submission-2 https://html.spec.whatwg.org/multipage/form-control-infrastr.... According to the mozilla docs, it was “Introduced by HTML5 for debugging purposes.” https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form#attr-enctype https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fo... But I doubt it was created by WHATWG either; in 2004 the HTML5 editor Ian Hickson said “I agree it is brain-dead (it's IE-compatible)” https://lists.w3.org/Archives/Public/public-whatwg-archive/2004Jun/0395.html https://lists.w3.org/Archives/Public/public-whatwg-archive/2... Unfortunately I can’t see history of the spec before 2006 though https://github.com/whatwg/html https://github.com/whatwg/html