HTTP/2 is it the correct path?
Nov 26, 2018


Here we go again... Another layer upon more layers. I will not go into the crap we have to put with in HTTP/.9  /HTTP/1.0,  HTTP/1.1,  SSL, TSL, and TCP now we have HTTP/2, does it solve anything. The HTTP/2 95 page specification does nothing to reduce complexity of information exchange. The first thing that struck me about the specification was the same convention of a client and server, this is not going anywhere.

More fixed length binary values in the HTTP/2 specification. A frame length limit of 16,384 unless something something or something... 8 bit types and flags. Someone decided that this will be good enough for the next thousand years, or the next release which ever comes first. I wish programmers would quit putting limits on everything. 

The frame type:
An eight bit predefined hard coded numeric value. A fixed application with no hope for expansion. The specification is crap, using abbreviated words to define numeric values.  RST instead of spelling out RESET, this only goes to prorogate misunderstanding of use.

Setting Parameters:
Again fixed number of bits binary value hard coded to documentation.  A bad specification on the exact meaning and use of preset parameters (I have no idea what they mean by WINDOW, among others...)

Security:
Not secure for very long, how many versions of versions is acceptable. We only know about a few very obvious hacks, what about all the others? If I broke your security, would I tell you? I do not trust any of these so called security systems. Having private security systems make more sense.

Not the right approach... why secure public information,  time wasted.  I would prefer to know that very special care of my banking information is being handled better than my listing of a cake recipe. DO NOT LOCK every page, use a simple fast security for public data, take the "LOCK" image off the page, I want full deep security and know that it is handled special when I'm entering my credit card numbers (put the LOCK image on in this case).  To lock every page is the wrong path, I cannot trust anything or it is so slow at to make it worthless (if done right)
 

The HTTP/2 is simply an application for packet transfer, not packet content. I would prefer to see a more complete specification. Some of the thing I would like is less programming and better content handling:
  1. The packet description should be self defining (never need a new version)
  2. That all numeric values be infinite in size
  3. keep out application specific needs from the specification (PROMISE, handled but not needing to be part of the specification)
  4. No distinction should be made between client and server
  5. Remove all previous specifications (rewrite the browsers and web servers)
  6. Implement data transfer at the compiler level (program once, usable by every application)
  7. Be more realistic in what numeric encoding does or does not do. Never assume... which is what it does in HTTP/2

Instead of HTTP/2 (another application on top of a known flawed specification), redesign the complete system. We need less programming not more. The HTTP/1.0 and HTTP/1.1 is not being replaced. It was near impossible to program even the most trivial implementation of these protocols. Now we must implement another packet handler, we must also implement SSL/TSL logic as well, something that has only been done even by massive efforts.  If we look at Intel's instruction set as an example of a layered specification, which started out at 107 pages (8080 pocket Guide 1977, 3.5" x 4.5") of documentation now requires 2,300 full size pages. I think human time is more valuable than computer time.

I will implement HTTP/2 in Jane (for the users), but will implement my own data transfer specification that concentrates on content handing not just packet handling, and handled by the language (i.e. A = B) transfer a file from one application to another, or from one machine to another. Since Jane is the client and server, it makes no difference where information goes, and we should not care how.

Yes I think HTTP/2 is the wrong path. To add just a few new transport capabilities,  we do not need to create a whole new technology layer. I hate application specific technologies that have no real value. I will not know if anything is really secure. It will definitely sell hardware, which will be needed to add yet another reformatting of content that will slow down the transporting of information. If we ask ourselves how many bytes of information really need to be secured? I think we will find maybe 0.0001% of data that we need absolute secure, which unfortunately we cannot accomplish. Be realistic in what HTTP/2 is trying to accomplish.  Security should not be it, security should be totally excluded from just another really lame programming task. To containment  information technology with yet another layer will delay technology even more... It will however make job, sell hardware, and sell books. It will push more of our technology into the hands of monopolies.

In the end reduce programming do not make it more complicated.