Chunked transfer encoding - browser behavior
Fix your headers.
- As of 2019, if you use
Content-type: text/html
, no buffering occurs in Chrome.
- If you just want to stream text, similar to
text/plain
, then just usingContent-type: text/event-stream
will also disable buffering.
- If you use
Content-type: text/plain
, then Chrome will still buffer 1 KiB, unless you additionally specifyX-Content-Type-Options: nosniff
.
RFC 2045 specifies that if no Content-Type
is specified, Content-type: text/plain; charset=us-ascii
should be assumed
5.2. Content-Type Defaults
Default RFC 822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as:
Content-type: text/plain; charset=us-ascii
This default is assumed if no Content-Type header field is specified. It is also recommend that this default be assumed when a syntactically invalid Content-Type header field is encountered. In the presence of a MIME-Version header field and the absence of any Content-Type header field, a receiving User Agent can also assume that plain US-ASCII text was the sender's intent. Plain US-ASCII text may still be assumed in the absence of a MIME-Version or the presence of an syntactically invalid Content-Type header field, but the sender's intent might have been otherwise.
Browsers will start to buffer text/plain
for a certain amount in order to check if they can detect if the content sent is really plain text or some media type like an image, in case the Content-Type
was omitted, which would then equal a text/plain
content type. This is called MIME type sniffing.
MIME type sniffing is defined by Mozilla as:
In the absence of a MIME type, or in certain cases where browsers believe they are incorrect, browsers may perform MIME sniffing â guessing the correct MIME type by looking at the bytes of the resource.
Each browser performs MIME sniffing differently and under different circumstances. (For example, Safari will look at the file extension in the URL if the sent MIME type is unsuitable.) There are security concerns as some MIME types represent executable content. Servers can prevent MIME sniffing by sending the X-Content-Type-Options header.
According to Mozilla's documentation:
The
X-Content-Type-Options
response HTTP header is a marker used by the server to indicate that the MIME types advertised in theContent-Type
headers should not be changed and be followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a way to say that the webmasters knew what they were doing.
Therefore adding X-Content-Type-Options: nosniff
makes it work.
afaik browsers needs some payload to start render chunks as they received.
Curl is of course an exception.
Try to send about 1KB of arbitrary data before your first chunk.
If you are doing everything correctly, browsers should render chunks as they received.