ExoMedia icon indicating copy to clipboard operation
ExoMedia copied to clipboard

Documentation: Accept redirects 301/302 and "Cleartext HTTP traffic to xxx not permitted"

Open smarek opened this issue 4 years ago • 5 comments

  • [x] I have verified there are no duplicate active or recent bugs, questions, or requests
Include the following:
  • ExoMedia version: 4.3.0
  • Device OS version: 10.0
  • Devide Manufacturer: Motorola
  • Device Name: Motorola One
Reproduction Steps
  1. Play video from url http://i.imgur.com/SxwNI7f.mp4
Expected Result
  1. ExoMedia should accept the 301 response and redirect to HTTPS version of the linked video
Actual Result
2020-11-10 10:45:15.105 32756-1124/mareksebera.cz.redditswipe E/ExoPlayerImplInternal: Source error.
    com.google.android.exoplayer2.upstream.HttpDataSource$HttpDataSourceException: Unable to connect to http://i.imgur.com/QljaMs3.mp4
        at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.open(DefaultHttpDataSource.java:281)
        at com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:250)
        at com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:83)
        at com.google.android.exoplayer2.source.ExtractorMediaPeriod$ExtractingLoadable.load(ExtractorMediaPeriod.java:885)
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:381)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:919)
     Caused by: java.io.IOException: Cleartext HTTP traffic to i.imgur.com not permitted
        at com.android.okhttp.HttpHandler$CleartextURLFilter.checkURLPermitted(HttpHandler.java:124)
        at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:462)
        at com.android.okhttp.internal.huc.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:131)
        at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.makeConnection(DefaultHttpDataSource.java:528)
        at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.makeConnection(DefaultHttpDataSource.java:436)
        at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.open(DefaultHttpDataSource.java:279)
        at com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:250) 
        at com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:83) 
        at com.google.android.exoplayer2.source.ExtractorMediaPeriod$ExtractingLoadable.load(ExtractorMediaPeriod.java:885) 
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:381) 
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) 
        at java.lang.Thread.run(Thread.java:919) 

I've seen the #691 which touches the same subject, however the solution should be different, than setting usesCleartextTraffic in app manifest

According to docs https://exoplayer.dev/troubleshooting.html#why-do-some-streams-fail-with-http-response-code-301-or-302

If you need to, you can configure ExoPlayer to follow cross-protocol redirects when instantiating DefaultHttpDataSourceFactory instances used in your application. Learn about selecting and configuring the network stack here.

Probably something along the lines of solution in #581, specifically https://github.com/brianwernick/ExoMedia/issues/581#issuecomment-375680794

I've personally tested this as valid solution

public class MyApplication extends Application {
  @Override
  public function onCreate() {
    super.onCreate();

    ExoMedia.setDataSourceFactoryProvider((userAgent, listener) -> new DefaultHttpDataSourceFactory(userAgent, listener, DefaultHttpDataSource.DEFAULT_CONNECT_TIMEOUT_MILLIS, DefaultHttpDataSource.DEFAULT_READ_TIMEOUT_MILLIS, /* allowCrossProtocolRedirects= */ true));
  }
}

So I'd suggest putting up some documentation, and maybe update comment in the #691 so devs do not get advised to allow all cleartext traffic if it's not absolutely necessary

smarek avatar Nov 10 '20 10:11 smarek

Sorry i'm an idiot, the code for accepting redirects is correct, however it has to be coupled with android:usesCleartextTraffic if you have to accept user-provided links to content, even if the response to HTTP GET request is just 301/302 with no response body.

smarek avatar Nov 12 '20 06:11 smarek

Sorry i'm an idiot, the code for accepting redirects is correct, however it has to be coupled with android:usesCleartextTraffic if you have to accept user-provided links to content, even if the response to HTTP GET request is just 301/302 with no response body.

lmao! You still use this library? 😂

XiXiongMaoXiong avatar Nov 16 '20 17:11 XiXiongMaoXiong

Sorry i'm an idiot, the code for accepting redirects is correct, however it has to be coupled with android:usesCleartextTraffic if you have to accept user-provided links to content, even if the response to HTTP GET request is just 301/302 with no response body.

lmao! You still use this library? xD

What? Deprecated?

smarek avatar Nov 16 '20 17:11 smarek

Sorry i'm an idiot, the code for accepting redirects is correct, however it has to be coupled with android:usesCleartextTraffic if you have to accept user-provided links to content, even if the response to HTTP GET request is just 301/302 with no response body.

lmao! You still use this library? xD

What? Deprecated?

Of course silly! Most of the underlying implementations of this library are SUPER deprecated now and even some of them are NOT RECOMMENDED BY GOOGLE anymore. Use ExoPlayer itself! Read the documentation and learn it (if you think it is hard, it is not). Don't rely on dead libraries mate or you'll end up with a hell of bugs!

XiXiongMaoXiong avatar Nov 17 '20 02:11 XiXiongMaoXiong

Thanks @smarek I'll look at adding documentation that indicate the use of both to prevent confusion in the future.

@NotNotMarshall I agree that it has been a while since the last deployment, and ExoMedia is using an older ExoPlayer version, the methods being used were the most recent available in the ExoPlayer version used and the underlying OS implementation didn't change so is still stable.

brianwernick avatar Dec 03 '20 14:12 brianwernick