CODEWITHSUNDEEP
http
YoavKlein
YoavKlein

Reputation: 2703

What is the point in Transfer-Encoding chunked

I've read about chunked encoding in few places, but still don't quite get why for example a Radio streaming server such as this one sends its data as chunked Transfer-Encoding. A client of such server just continuously reads data from the server. It doesn't in any point needs to know how much data is currently being sent since it is always consuming data (as long as it stays connected).

It seems that the client doesn't use these pieces of data, he just discards them, which adds more job for him.. Can anyone explain this to me?

Upvotes: 2

Views: 2770

Answers (1)

Evert
Evert

Reputation: 99533

HTTP/1.1 needs to either send a Content-Length, or chunked encoding. If you can't know the length, you must use chunked encoding. A continuous stream would in theory have an infinite length.

A HTTP client needs either of these to know when the response ends. After the respons a new HTTP request could be sent.

You are correct that in the case of a continuous stream it's not needed to detect when the stream ends, because it doesn't. It could have been possible for the authors of HTTP/1.1 to have a third 'continuous stream of bytes' option for HTTP. Perhaps that use-case wasn't considered all those years ago.

Note that HTTP/2 doesn't have chunked encoding anymore, but it does something similar and sends multiple body frames.

Upvotes: 3

Related Questions