Which are dead simple to construct, send, receive and parse.

Really.

For example, let's curl -L (view everything but the body) for the spec: http://www.ietf.org/rfc/rfc7230.txt

HTTP/1.1 200 OK

Date: Tue, 24 Jan 2017 12:00:55 GMT

Content-Type: text/plain

Transfer-Encoding: chunked

Connection: keep-alive

Set-Cookie: __cfduid=df57c7720b704a40e4c3367bbe248771c1485259254; expires=Wed, 24-Jan-18 12:00:54 GMT; path=/; domain=.ietf.org; HttpOnly

Last-Modified: Sat, 07 Jun 2014 00:41:49 GMT

ETag: W/"3247b-4fb343e4dcd40-gzip"

Vary: Accept-Encoding

Strict-Transport-Security: max-age=31536000

X-Frame-Options: SAMEORIGIN

X-Xss-Protection: 1; mode=block

X-Content-Type-Options: nosniff

CF-Cache-Status: EXPIRED

Expires: Tue, 24 Jan 2017 16:00:54 GMT

Cache-Control: public, max-age=14400

Server: cloudflare-nginx

CF-RAY: 326353e6a6a257a7-IAD

A bunch of newline, (CRLF), seperated key-value mappings. Some with a DSL (Such as Set-Cookie).

It gives you a status message instantly, a date to check against cache, a Content-Type for your parser, acceptable encoding, for your parser, a bunch of other values for your cache. All for free.

As for the body of the content? For a gzipped value like this, it's everything outside the header, until EOF. That's not quite as easy as when the content-length parameter is given, but hardly difficult for parsing.

HTTP is easy.

In fact, HTTP is so easy, that in-complete HTTP servers can still serve up real content, and browsers can still read it.

HTTPS is more complicated, but if you simply rely on certificate stores and CAs, it becomes much easier, but HTTPS is a different protocol.