[HN Gopher] Evolution of HTTP
       ___________________________________________________________________
        
       Evolution of HTTP
        
       Author : divbzero
       Score  : 75 points
       Date   : 2022-10-14 10:23 UTC (1 days ago)
        
 (HTM) web link (developer.mozilla.org)
 (TXT) w3m dump (developer.mozilla.org)
        
       | bullen wrote:
       | The ONLY thing that has been constantly broken for 20 years is
       | HTTPS.
       | 
       | HTTP2+ IS HTTPS.
       | 
       | And it's the opposite of secure.
       | 
       | Use this over HTTP/1.1 instead:
       | https://datatracker.ietf.org/doc/html/rfc2289
        
       | RunSet wrote:
       | or:
       | 
       | "An argument for Gemini."
       | 
       | https://en.wikipedia.org/wiki/Gemini_(protocol)#Design
        
         | yoro46 wrote:
         | How exactly does linking a Wikipedia page to some minimalist
         | cult's redesign of Gopher present an argument for Gemini?
        
         | [deleted]
        
         | woodruffw wrote:
         | I've tried to drum up my own interest in Gemini, but it feels
         | very NIH.
         | 
         | Given that you can serve plaintext (or barebones HTML) over the
         | Web and that every browser will _still_ happily speak HTTP /1.0
         | or even HTTP/0.9, I don't understand the draw (other than the
         | nostalgic aesthetic).
        
           | 0x445442 wrote:
           | Yeah, I think a distinction needs to be made between
           | bastardized JS laden applications and documents with embedded
           | rich media. It's interesting the four bullet points in the
           | link all mention documents but HTTP hasn't been about
           | documents for a long time.
        
           | Cyberdog wrote:
           | A while back I hammered out an idea I call KyuWeb, which
           | specifies a document-based web using existing standards like
           | HTTP and reinvents as few wheels as possible. I haven't had
           | time/skill to hammer out a complete client implementation
           | yet, but I enjoy hearing feedback from people who have looked
           | over the specification. Have a look and see if it's to your
           | taste: https://github.com/GarrettAlbright/KyuWeb
        
           | ainar-g wrote:
           | From my understanding, the draw is to "start over" and create
           | a completely new hypertext ecosystem where script-heavy
           | advertising-laden sites just aren't technically possible. Or,
           | at the very least, extremely impractical. It's a moonshot,
           | but I guess that's one of the reasons they called it Gemini,
           | heh.
        
           | chrismorgan wrote:
           | HTTP/0.9 died long ago. Chromium shows an
           | ERR_INVALID_HTTP_RESPONSE error page, and Firefox renders the
           | response body as preformatted plain text rather than as HTML.
        
           | peoplefromibiza wrote:
           | no JS
           | 
           | no trackers or ads
           | 
           | no need for a CA
           | 
           | it's much easier to create a browser for it, it's in fact
           | something a single developer can do in a weekend project
           | 
           | it's not controlled by any corporation
        
             | notriddle wrote:
             | It mostly only solves problems on the consumer side. Only
             | one of these downsides directly affects publishers.
             | 
             | * If you don't want JS, don't use it.
             | 
             | * If you don't want trackers or ads, don't put them in.
             | 
             | * This is the only publisher-touching downside, and
             | LetsEncrypt is an effective mitigation.
             | 
             | * If you want to make a site Lynx-compatible, test it in
             | Lynx.
             | 
             | * The downsides of this are too diffuse to immediately
             | drive demand. Nobody is directly impacted by it.
        
               | peoplefromibiza wrote:
               | > Only one of these downsides directly affects
               | publishers.
               | 
               | on the client side it ensures that JS, ADS, trackers etc
               | won't be there and the client can bet there will be no
               | surprise
               | 
               | Gemini is the equivalent of "make the impossible states
               | impossible"
               | 
               | The best a malevolent publisher can do is look at the
               | logs, because not even the transparent pixel is allowed.
               | 
               | It's worth pointing out that the goal of Gemini is not to
               | replace the WEB and that it it is still possible to
               | publish pure HTML web sites with the same characteristics
               | (but for how long?)
               | 
               | also Gemini has no headers so no cookies, that, depending
               | on the platform, could be out of the control of the
               | publisher.
               | 
               | I am working (slowly) on some Gemini project
               | 
               | Mainly because there is no money involved in it and
               | monetisation is not a thing.
               | 
               | Gemini, for example, makes it really easy to build search
               | engines that actually work and cannot be weaponized
               | against their users
               | 
               | Because the protocol is so limited that it's impossible,
               | or highly impractical, to follow that route (no money
               | also means no incentive)
        
             | tsimionescu wrote:
             | It doesn't do most of the things we use the WWW for.
        
               | krapp wrote:
               | That's supposed to be the point. Gemini is the techie
               | version of running off into the woods to join an anarcho-
               | primitivist commune or an aescetic monastery.
        
               | peoplefromibiza wrote:
               | being limited is one of the selling points of Gemini.
        
       | superkuh wrote:
       | >The next major version of HTTP, HTTP/3, will use QUIC instead
       | TCP/TLS for the transport layer portion.
       | 
       | What an odd way of phrasing it. It should be, "The next major
       | version of HTTP, HTTP/3, will be QUIC and so drop TCP for UDP and
       | _require_ CA based TLS for every single connection. Regular
       | connections not requiring a third party corporation to approve
       | will be impossible. "
        
         | tialaramex wrote:
         | This isn't a change from the status quo. HTTP/2 is in practice
         | only used over TLS.
        
           | jen20 wrote:
           | It's also commonly used over domain sockets without TLS for
           | gRPC. Practically I'm not sure that QUIC makes a huge amount
           | of different for public services endpoints though, you're
           | right.
        
         | masklinn wrote:
         | > What an odd way of phrasing it. It should be, "The next major
         | version of HTTP, HTTP/3, will be QUIC"
         | 
         | No?
         | 
         | Http/3 is one application of quic, but sits on top of it.
         | 
         | That's why it has a separate RFC, which explains that:
         | 
         | > While delegating stream lifetime and flow-control issues to
         | QUIC, a binary framing similar to the HTTP/2 framing is used on
         | each stream. Some HTTP/2 features are subsumed by QUIC, while
         | other features are implemented atop QUIC.
         | 
         | While google did design QUIC with HTTP in mind, you can use
         | QUIC for other protocols e.g. Microsoft has shipped SMB on QUIC
         | in Windows Server 2022. MS also supports direct QUIC uses on
         | Xbox Series consoles and has a guide to use MsQuic with the
         | GDK.
        
           | iforgotpassword wrote:
           | > MS also supports direct QUIC uses on Xbox Series consoles
           | 
           | This is so fucking ridiculous. Tried writing my first android
           | app a few months ago, and for reasons wanted to do QUIC. I
           | was absolutely sure this was going to be a no-brainer, as
           | Google more or less being the inventor of it, or at least a
           | very strong proponent, must have made quic a first class
           | citizen of Android and its SDK years ago now. I mean, all
           | _their_ apps use it. Imagine how much in disbelief I was when
           | I learned there is nothing available, except a library that
           | wraps Chrome 's network engine and let's you use http3 over
           | quic, but not quic directly. You'd have to fiddle with using
           | a 3rd party native lib and some bindings and whatnot, so I
           | just deleted Android studio and went for a walk. Yes I'm
           | still bitter.
        
         | [deleted]
        
         | tenebrisalietum wrote:
         | You can make a self-signed CA certificate any time you want,
         | and anything with a browser will let you import it AFAIK. This
         | can be locked down on corporate Windows machines via Group
         | Policy, so this really only affects computers already behind
         | myriad layers of HTTP security layer gunk. You'll just have to
         | access your home streaming server from your phone over the
         | guest Wi-Fi.
        
         | judge2020 wrote:
         | If only browsers could read/install third party certificate
         | authorities, then you could do crazy things like serve an
         | internal domain securely via a certificate you generated
         | yourself, assuming the users agree to install your CA - or
         | better yet, you could be an enterprise purchasing computers for
         | your employees with the CA preloaded. Of course, that's not
         | possible right now.
        
           | n3t wrote:
           | Can one create a CA with a limitation to `*.example.com`?
           | 
           | Or can one install an arbitrary CA and limit it to
           | `*.example.com`?
        
             | zamadatix wrote:
             | Name Constraints allow for this.
        
               | Macha wrote:
               | Just be aware that support in non-browser software is not
               | so widespread and for something which doesn't understand
               | the extension, it's still effectively a global CA if
               | installed
        
               | jeffparsons wrote:
               | Be that as it may, this still doesn't seem like the big
               | deal that so many people are making it out to be. Support
               | for HTTP/1.1 and HTTP/2 won't be going anywhere fast, so
               | legacy software can keep doing what it's always done,
               | can't it?
               | 
               | HTTP/3 can be for people/applications that value what is
               | has to offer, and can largely be ignored otherwise.
        
             | midasuni wrote:
             | Name constraints allow it, if be happier if I could import
             | a certificate and set my own constraints in the certificate
             | manager - "I trust this for all *.bigcorp.com domains but
             | not for mybank.com"
        
             | tialaramex wrote:
             | If you don't care about older software, in particular older
             | Macs, yes, you can proceed as follows:
             | 
             | 1. Make CA #1 2. Make CA #2, have CA #1 sign (a certificate
             | for) this CA with a constraint saying it is valid only for
             | DNS names in example.com and nothing else 3. Destroy CA #1
             | irrevocably 4. Trust CA #1 in your browser or other relying
             | party software 5. You can now use CA #2 to issue with your
             | constraint.
             | 
             | If you care only about specific web browsers, you can
             | modify the browser software (this is practical for Firefox
             | and to some extent Chromium) to alter its built-in trust
             | semantics to give you chosen CA different constraints.
             | Firefox ships with constraints for a handful of CAs which,
             | in Mozilla's opinion, can be afforded such limited trust so
             | you can model your changes on how that works.
             | https://wiki.mozilla.org/CA/Additional_Trust_Changes
        
           | kevin_thibedeau wrote:
           | Firefox runs its own cert store so you can do precisely this.
        
             | lol768 wrote:
             | I think you missed the sarcasm.
        
       | rektide wrote:
       | I happen to be watching Steve Sanderson's _Why web tech is like
       | this_ presentation, which has some early history, runs the
       | original TBL projects. Might be fun for some interested in HTTP
       | 's (and a lot of other web tech, HTML/CSS/JS's) evolution:
       | https://www.youtube.com/watch?v=3QEoJRjxnxQ
        
       | yibberish wrote:
        
       | clumsysmurf wrote:
       | I long while back, there was a book called HTTP: The Definitive
       | Guide. Is there anything like it that is current?
        
         | ShamelessC wrote:
         | I'm assuming the linked article didnt quite do it for you
         | or...?
        
       ___________________________________________________________________
       (page generated 2022-10-15 23:01 UTC)