Opened 2 years ago

Last modified 2 years ago

#8642 new defect

HTTP 302 redirect to udp://

Reported by: barhom Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: http
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I am unsure if this is a bug or if it acts as it should be.
I have a use case where I use,

ffmpeg -i http://example.com/?ch=X

Which returns a 302 redirect to "udp://X:Y?pkt_size=1316"

* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 302 
< server: nginx
< date: Wed, 29 Apr 2020 08:10:09 GMT
< content-type: text/html
< location: udp://239.193.0.188:3301?pkt_size=1316
< access-control-allow-origin: *

The issue right now is that ffmpeg will try to establish a TCP connection (because the initial http connection was TCP).

Should a redirect of this kind work and then pull the input from udp:// ?

Change History (6)

comment:1 by Carl Eugen Hoyos, 2 years ago

Keywords: http added

If you want to report a bug, please test current FFmpeg git head and provide the command line you tested together with the complete, uncut console output.

comment:2 by Tomas Härdin, 2 years ago

What do you expect this to do? UDP is not an application protocol. Are you trying to have it upgrade to QUIC? There's a specific mechanism for that, but it's far from being standardized.

in reply to:  2 comment:3 by barhom, 2 years ago

Replying to cehoyos:

If you want to report a bug, please test current FFmpeg git head and provide the command line you tested together with the complete, uncut console output.

I guess this is more of a question to see if it is a bug or not first.
I am using the latest git.

Replying to Tjoppen:

What do you expect this to do? UDP is not an application protocol. Are you trying to have it upgrade to QUIC? There's a specific mechanism for that, but it's far from being standardized.

Short explanation:
I expect ffmpeg to start reading from UDP.

Long explanation:
This has nothing to do with QUIC. I am using a "load balancer" for my input of sort that gives a 302 redirect. This load balancer may return a http://, https:// or udp:// address.

I expect the following to happen;

If;

ffmpeg -i http://example.com/?ch=X

returns a 302 that looks like this;

location: udp://239.193.0.188:3301?pkt_size=1316

Then I expect ffmpeg to behave as if I had run,

ffmpeg -i udp://239.193.0.188:3301?pkt_size=1316

Do you see the use case?

comment:4 by Tomas Härdin, 2 years ago

Oh lord, there's a udp.c which implements some homegrown protocol based on top of UDP..

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.

in reply to:  4 comment:5 by barhom, 2 years ago

Replying to 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?

comment:6 by Tomas Härdin, 2 years ago

RTSP makes sense at least, but I'm unsure whether lavf is geared toward this. Perhaps someone else wants to weigh in?

Note: See TracTickets for help on using tickets.