In h开发者_StackOverflow中文版tml, I know there is a chunked encoding. Anyone knows its advantage?
It's not part of HTML - it's part of HTTP.
It means that you can start writing the content to the output stream before you know exactly how large the output is going to be. This means you don't have to buffer the whole page (or whatever you're delivering) in memory or on disk before you start transmitting.
You need to be aware of its disadvantages, too. Some firewalls/antiviruses want to download the complete response so they can inspect it, and will therefore block any incomplete response chunks from reaching the client.
A lot of firewalls have chunked encoding set to block by default, especially on corporate networks. If you want people to be able to reach your web service from their work computers, you need to either https the whole website (since https traffic cannot be inspected), or avoid chunked transfers.
The only situation that I can think of where that downside is justified is https streaming. If you don't need streaming, it's not worth it, in my opinion.
Responding to comment below here because I think it's important.
Network problems with chunked responses are very common. In my current project (B2B so every customer is behind a corporate network) I estimate roughly 3/4 customers experience issues.
To prove/disprove, I set up a test that sends 2 identical responses, one regular and one chunked (streaming chunks of html in 1 sec intervals for 3 minutes). Chunked response was consistently blocked (customer observed blank page) or accumulated (customer observed blank page for 3 minutes followed by complete rendering of html). Same chunked response was fine over https (customer observed incremental rendering of html in 1 sec intervals). I ran this on different customers/firewalls.
This is a known issue. You can read up on websockets, part of their appeal is that they help overcome these very common firewall/proxy problems.
精彩评论