[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] chunked encoding & mjpeg stream
From: |
Evgeny Grin |
Subject: |
Re: [libmicrohttpd] chunked encoding & mjpeg stream |
Date: |
Mon, 28 Feb 2022 19:14:36 +0300 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 |
Hello,
Looks like Chrome and Firefox just unable to process chunked encoding
together with multipart/x-mixed-replace.
Actually "multipart/x-mixed-replace" was never standardized for HTTP.
We have other forms of "multipart/" defined for HTTP:
* "multipart/form-data" for requests, see
https://datatracker.ietf.org/doc/html/rfc7578
* "multipart/byteranges" for "206 Partial Content", see
https://datatracker.ietf.org/doc/html/rfc7233#section-4.1 and
https://datatracker.ietf.org/doc/html/rfc7233#appendix-A
However, all these forms need to be compliant with HTTP specifications,
which require either "Content-Length" or "Transfer-Encoding" with
"chunked" as the final encoding. See
https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.3.
So, if you are sending this kind of response, you must either declare
the payload size in the header or use chunked-encoding.
Both Chrome and Firefox are slowly deprecating and removing support for
"multipart/x-mixed-replace".
See
https://bugs.chromium.org/p/chromium/issues/detail?id=249132 (dated 2013)
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/22
(released in 2013).
If you really need to use "multipart/x-mixed-replace" with browsers and
you don't know the size in advance, there is a workaround: use
MHD_create_response_from_callback() with MHD_SIZE_UNKNOWN as the size
and apply MHD_RF_HTTP_1_0_COMPATIBLE_STRICT flag
(MHD_RF_HTTP_VERSION_1_0_ONLY for older MHD versions). This will force
MHD to not use the proper chunked encoding and result should be readable
by browsers.
Let us know please if this solves the issue for you.
--
Evgeny
On 28.02.2022 1:06, folkert wrote:
Hello,
Some browsers (like chrome and firefox) get confused when showing an
mjpeg-stream when produced by libmicrohttpd. Most likely this is caused
by the chunked encoding.
An MJPEG stream consists of a "multipart/x-mixed-replace" http-stream of
jpeg images. After every jpeg frame, a multipart-header is added -
regular ascii with \r\n.
E.g.:
\r\n
--myboundary123\r\n
Content-Type: image/jpeg\r\n
Content-Length: 1234\r\n
\r\n
[... data ...]
Chunked encoding adds some data to it:
[pid 27739] sendto(7, "3A74\r\n\r\n--12345\r\nContent-Type:
image/jpeg\r\nContent-Length: 83519\r\n\r\n\
^^^^^^^^
and because of that, the browser often displays no video-frames at all
or only partially.
If I use a http-server which does not produce chunked encoding, things
work fine.
I would like to suggest to add a switch of some sort to disable chunked
encoding. I don't believe it is neccessary for things like mjpeg as the
size of each segment is already included ("Content-Length: 83519\r\n") in
multipart-scheme.
Regards
OpenPGP_signature
Description: OpenPGP digital signature