[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