HTTP/1.1 came out in 1997. It’s extremely well supported. Websockets were only standardised in 2011, and still have proxy traversal issues.

You can absolutely assume that http 1.1 will work on basically anything; websockets are more finicky even now, and certainly were back in the day.

Websockets are also on the far side of useless when it comes to streaming content the user is downloading. Javascript-filled pages are not the only clients of http.

It wouldn't be so bad, if web and application APIs made stream processing of messages possible. The protocol itself could handle streaming content just fine, or at least not worse than HTTP.

chunked-encoding is a method of encoding an HTTP response body. The semantics for HTTP responses still apply, caching, compression, etc.

Websocket is a different protocol that is started up via HTTP.

Web sockets have their own issues that can be/are implementation dependent.

For example, some websocket servers don't pass back errors to the client (AWS). That makes it quite difficult to, say, retry on the client side.

Chunked encoding is used by video players - so you can request X bytes of a video file. That means you don't have to download the whole file, and if the user closes the video you didn't waste bandwidth. There are likely more uses of it.

> Chunked encoding is used by video players - so you can request X bytes of a video file. That means you don't have to download the whole file, and if the user closes the video you didn't waste bandwidth. There are likely more uses of it.

Just a nitpick, but what you describe here is byte range requests. They can be used with or without chunked encoding, which is a separate thing.

Oh yeah, ugh - I get those two confused.

I would say rule of thumb, websockets are for two way realtime communication, http chunked is just for 1 way streaming communication.