HTTP key-value semantics

omg, my life has been a lie

Well, anyway, I just figured out some grown-up stuff, and I guess I should write it down while it's fresh. So in HTTP:

• query string parameters (key-value)
• cookie header parameters (name-value)
• form string parameters (name-value)
• ... (not sure if I missed anything else)

First of all, notice that the labels in all of these categories are not consistently termed. Some of their RFCs refer to the label as a 'key', and others refer to the label as a 'name'.

Second, and more importantly, each of these categories ALLOWS REDUNDANT LABELS, which is to say, you can have multiple instances of the same label per HTTP request, and therefore you can have multiple values under each label ... and therefore ...

... every single web application which auto-magically parses a HTTP request and defaults to passing a label-scalar instead of a label-array is a lie.

The semantically correct treatment for this should be label-array and it should be up to the developer to check the length of the array, before making use of the data in their application. Of course, you could argue that the point of frameworks is to reduce such boilerplate. But then I would just say that some frameworks are more obfuscating than others.

A protocol is a protocol. You can have frameworks that make protocols easier to work with, but frameworks which obscure the nature of protocol are bad frameworks. Throw them away. 

---

This learning triggered me a bit. In a separate post I decided that in the future I must explore a complete refactoring of HTTP/HTML to a new set of protocols ... and the goal will be to see if we can make it more performant than HTTP/HTML while tunnelling it over HTTP/HTML for compliance.