HTTP has become the default, universal communication protocol | Hacker News Reader

HTTP has become the default, universal communication protocol

utcc.utoronto.ca

32 pointsingve17 comments

We (the royal tech we) have taken a document transport protocol and bent it into a replacement for green-screen and installed general computing applications over the last 2+ decades.

The barrier to entry in building, supporting and maintaining web applications is low compared to installed apps from ye olden times using things like VB and floppy disk installs to many different OSes. There is a large mix of web stacks to choose from and building apps is essentially a "solved" problem at this point. Everything seems to build off HTTP, even cloud computing has REST API's to invoke functions to spin up compute resources. Everything has an API.

Not everyone should learn how to code but I think everyone should have a basic understanding of what HTTP does and what API's are and how to call them (via simple tools not coding). Its probably useful to nearly any professional (aka office worker) type of career.

> We (the royal tech we)

Isn't the 'royal we' using 'we' when talking about oneself? If you're actually talking about a group of people that's a plain old 'we' isn't it?

“The royal we” is sometimes (despite this definition not being popularly recorded and conflicting with the more common understanding) used as a “we” referring in general to a class with a statement that may or may not apply to the speaker personally. I think this comes fron the literal royal “We” including among its functions the monarch referring to themselves in their capacity as an embodiment of the State.

Isn’t this largely due to it being one of a handful of protocols that can get through typical corporate firewalls?

My thoughts exactly!

(worth a risk of my karma for this no-so-glib remark, but ICAP protocol is busy in that HTTP examination arena)

The Internet Content Adaptation Protocol (ICAP) is a lightweight HTTP-like protocol (request and response protocol), which is used to extend transparent proxy servers. This frees up resources and standardizes the way in which new features are implemented.

Use cases:

1. Antivirus Scanning: ICAP allows for integration with antivirus engines. When a client requests a web resource, the proxy server can send the content to an ICAP server with an antivirus scanning module

2. Data Loss Prevention (DLP): ICAP can be used to enforce data loss prevention policies. An ICAP server with DLP capabilities can inspect outgoing web content for sensitive information, such as credit card numbers or social security numbers.

3. Content Transformation: ICAP can be used to modify web content to adapt it for specific devices or network conditions.

4. Content Filtering: ICAP can be used to implement content filtering and censorship mechanisms. By connecting a proxy server to an ICAP server equipped with content filtering capabilities, organizations can enforce policies to block or modify specific types of content, such as malware, adult content, or unauthorized websites.

It is a whole new world, especially with HTTP/3 and its many variants.

I hope your meaning of "glib" was "I'm describing a bunch of technologies that should not exist".

An’it?

I have designed and spun-up a new ICAP server just to deal with malicious JavaScript by certain web servers used by dubious advertising companies for protecting my home and businesses.

Works better than uBlock Origin and NoJS.

So, the old cat-and-mouse game is now on a briskier pace.

Not just corporate firewalls, there a lot of overly pessimistically configured by default home/consumer firewalls, routers, and ISP NAT/CGNAT gateways in the wild. "UPnP" is a hack of a solution for that in the consumer space, and it sometimes mostly works, except when it silently breaks in ways that only confuse average users and blame the application rather than their (or their ISP's) hardware.

A bigger reason is all the tooling for HTTP. Every language has libraries for HTTP. There are lots of proxy servers and application servers. It works in the browser. It is all tested and reliable.

Also, a lot of uses fit the request-response model of HTTP. Does it make sense to make new protocol or adapt HTTP when it can do the same thing? It makes more sense to focus on the application logic.

In the future, cool kids would reply to each other in HTTP response code.

Kid1: Hey guys, GET /lunch? Kid2: 200 Kid3: Nah, 301 later

HTTP is the "Plastic" of the digital world.

Lots of downsides but highly malleable and useful.

And now our system is full of full of microplastics ahem microservices

> HTTP has become the default, universal communication protocol

No, it has not. It is redirected to https.

I think thats implied. Https practically to users (and many clients and servers) is no different than http, even though they're very different in implementation.

Just lipstick on a pig.

Same ol', same ol'.

except for encryption benefit, what difference these two has?

HTTPS is HTTP over TLS/SSL. It is still HTTP.

Reply on news.ycombinator.com