[FFmpeg-trac] #9444(avformat:new): No errors when a live stream is pushed to an invalid http endpoint

FFmpeg trac at avcodec.org
Thu Sep 30 12:33:58 EEST 2021

#9444: No errors when a live stream is pushed to an invalid http endpoint
             Reporter:               |                    Owner:  (none)
  damiano.falcioni                   |
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avformat
              Version:  4.2.4        |               Resolution:
             Keywords:  http 404     |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
Comment (by damiano.falcioni):

 Replying to [comment:2 Brad Isbell]:
 > FFmpeg doesn't send the {{{Expect: 100-continue}}} message.  Therefore,
 it is not possible for FFmpeg to know if there is a 404 or some other
 error status code, as the server isn't allowed to respond until the entire
 request body is sent.  So, in the case of an indefinite length stream,
 such as your webcam, the HTTP request just continues running unless the
 server closes the underlying socket.
 > So, I think what you're asking for is an enhancement to add support for
 {{{100 Continue}}} responses, and for {{{Expect: 100-continue}}} to be
 added by default to HTTP requests.  (And, it'd be good to verify that this
 doesn't mess up Icecast connections.)

 Hi Brad, thanks for the suggestion.
 I see that there is already the parameter -send_expect_100 so I tried:

 % ffmpeg -loglevel trace -f v4l2 -i /dev/video0 -f mjpeg -send_expect_100
 1 http://example.com/404


 [http @ 0x55ba4110be40] request: POST /404 HTTP/1.1
 Transfer-Encoding: chunked
 User-Agent: Lavf/58.29.100
 Accept: */*
 Expect: 100-continue
 Connection: close
 Host: example.com
 Icy-MetaData: 1

 [http @ 0x55ba4110be40] header='HTTP/1.1 100 Continue'
 [http @ 0x55ba4110be40] http_code=100
 [http @ 0x55ba4110be40] header=''
 Successfully opened the file.


 So I think FFMPEG handle it correctly, and the problem is on the web
 server that return {{{ HTTP/1.1 100 Continue }}} also on 404 pages (I
 checked already this with Wireshark).
 This looks a quite common problem because occur on sites like example.com,
 github.com, and also on my innovation-laboratory.org (based on apache
 2.4.29), but not on google.com.
 I will further investigate.
Ticket URL: <https://trac.ffmpeg.org/ticket/9444#comment:3>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list