Allow performing requests for URLs that do not contain a host

[kmcbride]

Certain URL types supported by NSURLSession are valid even though they do not contain a host property. Previously, the data loader would not even attempt to request these URLs. With this change it is possible to load local files as well as data URIs.

[gitrema]

SPTDataLoader was written with the intention to be a network library and more specific to handle HTTP requests and being implemented on top of URLSession to reduce its binary footprint. Allowing requests that are not meant to be HTTP to go through, it means to expand the surface in which the library operates so I would have expected to see an improvement in error reporting instead of allowing different types of URLs to go through.

[kmcbride]

@gitrema fair point, though as far as I can tell nowhere in the library has it ever been enforced that requests or responses be limited to HTTP(S) — if that is the intention then I'm surprised by the lack of code doing anything to prevent otherwise. It seems to me that the use case addressed in this PR was originally supported and is now broken (probably unintentionally) because of a change to nullability handling: host resolution introduction → resolved host nil check → nullability refactor

[gitrema]

Thanks for pointing out the history by sharing previous PRs. I cannot find any mention in the README about usage of SPTDataLoader for something else other than networking. It does not mean that cannot be used to load other type of URLs of course even though it might not have been the intended use case. With that said if this PR is meant as bug-fix of a previously allowed behaviour it makes sense to merge it even though I would have personally preferred to take the opportunity to restrict requests to network protocols only.

[kmcbride]

I will go ahead and merge this to restore the functionality. If it's decided that request scheme restrictions should be enforced, it can be done further up the call stack (eg: here).

[kmcbride]

@gitrema I just noticed that this portion of the readme specifically calls out support for protocols beyond HTTP.