| I'm not as familiar with HTTP 2, so I'll only talk about the previous specifications... 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. |
This is chunked and keep- alive. Things get a little trickier