The trick that really opened my eyes was this:

  $ telnet google.com 80
  Trying 142.250.70.238...
  Connected to google.com.
  Escape character is '^]'.
  GET / HTTP/1.1

  HTTP/1.1 200 OK

Then adding a couple of headers - and realising that it really was just text. You can really tell the difference with young developers who've made that leap.

Ditto for HTTPS:

    % openssl s_client -quiet -connect  google.com:443
    depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
    verify return:1
    depth=1 C = US, O = Google Trust Services, CN = GTS CA  1O1
    verify return:1
    depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com
    verify return:1
    GET / HTTP/1.1
    Connection: close
    
    
    HTTP/1.1 200 OK

I did Tech support at a small ISP a while ago, and this was part of our first day of training. So was sending email via telnet. There was an optional challenge to add an attachment.

I'm old enough to remember the good ole days of "telnet whitehouse.gov 25" and sending email to friends.

I find CGIs very interesting when scaling towards n=1 – they just do a bit of parsing and add no dependencies to your project. And with very few code (and still no dependencies) you get tiny, useful tools (plug alarm!) like https://demo.mro.name/geohash.cgi

Similar to this, upon reading the often recommended book Designing Data Intensive Application, I realize that the concept of a system and the optimization of one is simply a combination of read/writes, storage, I/O, bottlenecks. It's the layers upon layers of work that's been done on it that makes it work the way it does now.

I think it would be easier to just have them look at the network tab of the developer tools of whatever web browser. It will break down requests and responses for you to easily see. I suspect a very small percentage of the web in just plain text. Most of it is encrypted, and if you ignore that, most of it is compressed, and if you ignore that HTTP/2 and HTTP/3 are not plain text.

HTTP/2 and /3 are where "the web" really changes to become just another shitty network protocol. The beauty of HTTP was in it being hyperTEXT; now it might as well be some Novell crap.

I know that there are Reasons and blablabla but at an emotional level it's the end of an era, same to all these sites going React. The web used to be built on simple and easily-understandable tech, and now it just isn't.

>The beauty of HTTP was in it being hyperTEXT

No, HTTP is for TRANSFERRING hypertext. There is no reason that the transfer protocol needs to work in plain text (on top of TCP which isn't plain text either).

Too much abstraction, and not enough diversity. How many exercises could you make around looking the network tab on a browser? With the approach based on sockets, they have to implement the http protocol ( or a subset of it), synchronize the client and server, and if you have a multithreaded server, you get to implement connection keep alive and things like that. The depth you go is much much different!

>How many exercises could you make around looking the network tab on a browser?

I was not suggesting to do an exercise. If the goal of your exercise is to show that the web is built off text being passed back and forth it can easily be shown by just looking at the network tab. From a web development perspective the exact details of how HTTP packets are encoded are not that important. For the same reason a deep knowledge of TCP is not really important.

Yea, I'm a big support of that approach.

My introduction to web programming was raw PHP and it removes any illusions about this stuff being fancy.

This is still my favorite way to garner a path forward in a language / ecosystem. Remove the fluff at first and - if you reinvent the wheel, at least you get to see the power (or lack thereof) of the language - then start digging into paradigms and libs offered to help you grow with.

So your students do not have a networking class where this (not the programming part) should be taught in the first place?

They do have since last year (it used to be after my class, on the third year). It’s called Computer Networks and they learn things about configuring network hardware, OSI layers, etc. However, the “enlightenment” comes not from all the talk in that class, but latter when they start messing with the sockets, sending text back and forth, implementing chat services (and their own adhoc protocols), until they implement web “things” using only text (through the socket) and a browser..

Granted, not everyone of them will really understand all the nuances of what I try to teach them, but hopefully they’ll get some of it, and be better professionals than without that knowledge.

Simples, rápido e eficaz!