[FFmpeg-trac] #8642(undetermined:new): HTTP 302 redirect to udp://
FFmpeg
trac at avcodec.org
Thu Apr 30 00:22:16 EEST 2020
#8642: HTTP 302 redirect to udp://
-------------------------------------+-------------------------------------
Reporter: barhom | Owner:
Type: defect | Status: new
Priority: normal | Component:
| undetermined
Version: unspecified | Resolution:
Keywords: http | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by barhom):
Replying to [comment:4 Tjoppen]:
> Oh lord, there's a udp.c which implements some homegrown protocol based
on top of UDP..
I don't really understand the joke(?) here.
> http.c is explicitly only allowing http and https for redirects in
ff_http_do_new_request2() so it seems to acting like it should. I'm not
even sure HTTP allows redirecting to non-HTTP. I suppose it's conceivable
that it should be able to redirect to ftp or even gopher.
Yeh, I do not think the current behavior is wrong. I'm asking the
community of what they think. Shouldn't ffmpeg support 302 redirects that
returns, udp:// (goto udp.c), srt:// (goto libsrt.c) rtsp:// (goto rtsp.c)
etc?
At least in my own use case where I use a "load balancer" of sorts. It
would be great if ffmpeg has the ability to follow 302 redirects no matter
if the response location would be http, https, udp, srt, rtsp etc.
Does anyone have any thoughts on how to improve http.c to support jumping
protocols depending on 302 responses?
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8642#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list