Anki-android: Reviewer: URLs starting with "//" do not load

Created on 4 May 2020  路  9Comments  路  Source: ankidroid/Anki-Android

Anki loads URLs beginning with //, AnkiDroid fails

My presumption: In AnkiDroid, // refers to the root of the filesystem, rather than a selection between HTTP or HTTPS

Card source

<img alt="6.1 Russian road sign.svg" data-file-height="2250" data-file-width="1500" decoding="async" height="75" src="//upload.wikimedia.org/wikipedia/commons/thumb/5/50/6.1_Russian_road_sign.svg/50px-6.1_Russian_road_sign.svg.png" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/5/50/6.1_Russian_road_sign.svg/75px-6.1_Russian_road_sign.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/5/50/6.1_Russian_road_sign.svg/100px-6.1_Russian_road_sign.svg.png 2x" width="50"/>

Chrome error

75px-6.1_Russian_road_sign.svg.png:1 Failed to load resource: net::ERR_INVALID_URL

Card works if the sources are changed from // to https://

_Originally posted by @david-allison-1 in https://github.com/ankidroid/Anki-Android/issues/6101#issuecomment-623341776_

Accepted Good First Issue! Help Wanted Keep Open Reviewer

All 9 comments

shouldInterceptRequest fires, but shouldOverrideUrlLoading doesn't

On a sample card:

request.getUrl().toString():
file://upload.wikimedia.org/wikipedia/commons/thumb/e/eb/6.4_Russian_road_sign.svg/75px-6.4_Russian_road_sign.svg.png

The above is a shame as it doesn't contain the // prefix, I've had a shot at the overloads, and none seem to provide it.

We can fix this by mapping file:// -> http(s), and file:/// to file:///.

Relative URLs come in as file:///:

file:///storage/emulated/0/AnkiDroidTEST/collection.media/paste-33779ea505e78e7dd39c14eadb3741ab51cb52f9.png


This leaves the questions:

  • [ ] Does Anki use HTTP, or HTTPS?
  • [ ] Do we want to restrict file:/// URLS to be inside collection.media (if not done already)? I really want to do this from a security perspective.

Those aren't valid URLs are they? Why would we accept URLs without a scheme? Seems Anki upstream should reject them too? Or am I missing some chunk of URL RFC that says "in the absence of a scheme this is the default..." ?

Those aren't valid URLs are they? Why would we accept URLs without a scheme? Seems Anki upstream should reject them too? Or am I missing some chunk of URL RFC that says "in the absence of a scheme this is the default..." ?

// as a prefix is valid as it's a Protocol Relative URL

I believe this is: https://tools.ietf.org/html/rfc3986#section-4.2

I do love reading RFCs 馃 - almost always learn something. HTTPS is my strong preference, and agreed on restricting file:/// to be in collection - willing to reconsider if there is a revolt after attempting it but would try first

Hello 馃憢, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like _still searching for solutions_ and if you found one, please open a pull request! You have 7 days until this gets closed automatically

Hello 馃憢, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like _still searching for solutions_ and if you found one, please open a pull request! You have 7 days until this gets closed automatically

Much easier now, we're HTTPS only

Sounds cool

I've tried to fix this, it works on my Android 9, but it's not feasible, and there were issues with timeouts on lower APIs

The problem is that shouldInterceptRequest won't allow you to respond with a HTTP 3xx.

This means a synchronous call to OkHTTP to obtain the image.

A synchronous blocking call isn't feasible - it can theoretically block until a HTTP timeout.

So I'll add a snackabar and a message.

Was this page helpful?
0 / 5 - 0 ratings