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.

Replacing HTTP/HTML, and Tunnelling the Replacement Over HTTP/HTML

as an ode to how much I hate doing web development

That's it. I'm fucking pissed. (Not more than usual - but today, I have a special announcement.) I am now putting on my to-do list a rewrite of the protocol set { HTML, CSS, HTTP } and to demonstrate how to implement a simpler but fully-featured replacement ... and who cares if it's not broadly adopted ... I'll just have to show how it's going to be more performant even if we tunnel it through the old protocol set ... !

"What's wrong with HTTP/2?"

I'll own up to being a plebe and I'm only concerned with the application layer. (Just read up on HTTP2 briefly - looks like HTTP2 leaves the application layer pretty much the same.) I'm looking to deconstruct all of METHODS, HEADERS, maybe a good chunk of the boilerplate that we call markup ... and just regularise it to a flat single dimensional format. LOL

Bad Analogy: we need "a Visa/Mastercard network for Sundry Contracts"

Can someone PLEASE (maybe a well-distributed e-wallet provider) just write a generic interface for producers (upstream) to confirm real-time contracts - and then sell API access to customer-facing parties (downstream) ... so that we minimise the problem of 100 downstream customer-facing parties (delivery service, platform, aggregator, etc.) asking every upstream factory (restaurant, grocer, service provider, etc.) to install their goddamn order-booking software and hardware? LLOLL just take 0.05% of gross sales. Everyone wins. It's just a contract (NOT PAYMENT) interconnect layer for supply-chain integration. But we can dumb it down farther and very badly abstract it to the analogy: a Global Telephone Exchange for E-commerce Contracts.

TLDR: Your hardware stinks; your software smells; I don't want it in my house; those parts of your business are not integral to that service which you provide. 

But of course, that's just wishful thinking. Downstream businesses are free to demand that upstream businesses use their software and hardware. I was just you know, blue-skying, as they say.

View this post on Instagram

Besfren helps me to elaborate on my problems.

A post shared by 正 (@_jerng) on May 25, 2020 at 8:45am PDT

"What about [services that let restaurants order things from suppliers]?"

I kinda get how [those services] work []. There are a number of folks doing that business model []. However, notice that they are not yet integrating upstream from food delivery platforms. I like what they're doing, but it's not broad enough in the horizontal I'm complaining about. What about haircuts, and plumbing services? I would be curious to see more of that, when it happens. The goal being to go very thin, and very broad, not deep. I'm looking for an implementation that is COMMERCIALLY ATTRACTIVE to anyone who currently builds their own order-placing hardware and software and sends it upstream to factories. The market penetration of the generic order-making middleware has to be so good that people would rather use the middleware than (build their own order-making system and ask clients to use it).