ffmpeg does not report upload failures when PUTting content to a remote WebDAV server

[anonymous_coward]

Summary of the bug:
ffmpeg does not report upload failures when PUTting content to a remote WebDAV server.

I'm trying to send HLS content to a remote server using ffmpeg. The server requires Digest authentication. Credentials are provided in the URL, which ffmpeg correctly extracts.

ffmpeg opens the connection and sends the request headers, including Expect: 100 Continue, but obviously cannot include the Authorization header at this point. The server responds 100 Continue (rather than eg a 401 Unauthorized), so ffmpeg assumes no auth is needed and continues to send the body.

Once the request is complete, the server makes a final response with 401 Unauthorized but it seems that, once the connection is opened and 100 is received, ffmpeg no longer cares for the rest of the response and never checks again (it's just flushed when the connection is closed) so it doesn't see that the request failed, and it doesn't retry with the provided digest parameters.

I am aware that the server should probably respond to the Expect with 401 Unauthorized, but it also seems to me that ffmpeg ought to consume the server's final response and see that the request ultimately failed for some reason and report that back, instead of just assuming everything was successful. Ideally ffmpeg would then retry with the relevant authorization.

How to reproduce:

ffmpeg -re -stream_loop -1 -i example.avi -c:v:2 libx264 -x264-params "nal-hrd=cbr:force-cfr=1" -b:v 1M -maxrate:v 1M -minrate:v 1M -bufsize:v 1M -preset ultrafast -g 30 -sc_threshold 0 -keyint_min 30 -c:a:0 aac -b:a:0 96k -ac 2 -f hls -hls_list_size 10 -hls_time 2 "https://username:password@example.com/stream.m3u8"
ffmpeg version N-109029-g1800a0da09 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04)
  configuration: --enable-gpl --enable-static --enable-libsrt --enable-libx264 --enable-gnutls --extra-libs='-lpthread -lm' --ld=g++
  libavutil      57. 42.100 / 57. 42.100
  libavcodec     59. 52.100 / 59. 52.100
  libavformat    59. 34.101 / 59. 34.101
  libavdevice    59.  8.101 / 59.  8.101
  libavfilter     8. 50.100 /  8. 50.100
  libswscale      6.  8.112 /  6.  8.112
  libswresample   4.  9.100 /  4.  9.100
  libpostproc    56.  7.100 / 56.  7.100
[avi @ 0x7ffff574ebc0] non-interleaved AVI
Input #0, avi, from 'example.avi':
  Metadata:
    software        : MEncoder 1.5-7
  Duration: 00:10:34.53, start: 0.000000, bitrate: 15032 kb/s
  Stream #0:0: Video: h264 (High) (h264 / 0x34363268), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 15018 kb/s, 60 fps, 60 tbr, 60 tbn
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 0x7ffff57709c0] using SAR=1/1
[libx264 @ 0x7ffff57709c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x7ffff57709c0] profile Constrained Baseline, level 4.2
[libx264 @ 0x7ffff57709c0] 264 - core 155 r2917 0a84d98 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=30 keyint_min=16 scenecut=0 intra_refresh=0 rc_lookahead=0 rc=cbr mbtree=0 bitrate=1000 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=1000 vbv_bufsize=1000 nal_hrd=cbr filler=1 ip_ratio=1.40 aq=0
[hls muxer @ 0x7ffff57fa040] No HTTP method set, hls muxer defaulting to method PUT.
Output #0, hls, to 'https://username:password@example.com/stream.m3u8':
  Metadata:
    software        : MEncoder 1.5-7
    encoder         : Lavf59.34.101
  Stream #0:0: Video: h264, yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 1000 kb/s, 60 fps, 90k tbn
    Metadata:
      encoder         : Lavc59.52.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 1000000/0/1000000 buffer size: 1000000 vbv_delay: N/A
[hls @ 0x7ffff5755f00] Opening 'https://username:password@example.com/stream0.ts' for writing
[https @ 0x7ffab0004480] Opening 'https://username:password@example.com/stream.m3u8' for writing
[https @ 0x7ffab0004480] Opening 'https://username:password@example.com/stream1.ts' for writing

[anonymous_coward]

Further data point: if http_persistent option is set to 1 the receive buffer is not flushed, subsequent requests immediately consume the final response of the previous request (receiving the 401) rather than waiting for the 100 Continue as it should.

ffmpeg really needs to consume the final response at the end of each request.

[pds412]

Hello, I am having a similar issue when trying to push hls segments via POST requests to a remote server with the http_persistent option. Since ffmpeg doesn't check the responses after the first one, it cannot catch http errors. Additionally, my server won't write the last few segments to disk because ffmpeg's process is already down and not listening to its responses anymore.
Did you ever find a workaround for this problem?
Thanks!