Documentation: Accept redirects 301/302 and "Cleartext HTTP traffic to xxx not permitted"
See original GitHub issue- 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
- Play video from url
http://i.imgur.com/SxwNI7f.mp4
Expected Result
- 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
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (1 by maintainers)
Top GitHub Comments
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.
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!