[FFmpeg-devel] [Patch] Use Transfer-Encoding: chunked (and perhaps PUT) for HTTP uploads

Tomas Härdin tomas.hardin
Mon Dec 21 14:58:23 CET 2009


Good afternoon all

While attempting to have libavformat write data using HTTP we discovered
that the current implementation does not adhere to the HTTP RFC
(http://www.ietf.org/rfc/rfc2068.txt). Most importantly, it does not use
chunked encoding when lacking a known Content-Length (which is something
it always lacks).

To remedy this I added the flag "chunked_upload" to HTTPContext and
modified http_connect(), http_write() and http_close() appropriately.
This makes HTTP uploads behave more correctly. To be more specific,
libavformat now correctly interacts with libmicrohttpd and
com.sun.net.httpserver.HttpServer.

Also, I believe using POST is incorrect - compare section 9.5 to section
9.6 in the RFC. Using PUT would bring the code closer to the RFC, except
in rare cases where the server has some resource which accepts anonymous
media uploads and supplies a Location header in its response. For
example, writing to http://user:password at example.com/media/output.avi
should use PUT whereas http://user:password at example.com/media/ should
*probably* use POST. With this in mind, I've attached two patches - the
first simply fixes the encoding issue and sticks with POST, while the
other uses PUT. I haven't added any logic for switching to POST though,
as that would require somewhat dubious speculations on the given URIs.

One problem that I predict with this patch is that it won't work with
HTTP/1.0 servers since they can't handle chunked encoding. In that case
http_open() must either choose to use some multipart encoding if the
server supports that, or fail since Content-Length is unknown.
Considering the current code is incompatible with HTTP/1.0 anyway, this
shouldn't be any less incorrect.

Finally, some improvements would be to use a buffer so it doesn't send
too many tiny chunks, and calculating an MD5 hash for Content-MD5.

Both patches pass regression tests (they don't seem to test any
protocols though).

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http_post.diff
Type: text/x-patch
Size: 2778 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091221/607d1800/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http_put.diff
Type: text/x-patch
Size: 3751 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091221/607d1800/attachment-0001.bin>



More information about the ffmpeg-devel mailing list