A clarification in document

[stkim1]

A clarification in document

[Redundancy]

You're right - the existing implementation does do something that I explicitly warn against. Note that hypothetically speaking, including cache-busting headers in the responses can help.

The main reason that I don't do it is that it's quite prescriptive to decide to use HTTP1.0 and come up with an appropriate scheme for chopping up the payload. The ideal situation would often be to match the granularity to your units of change (as described a bit lower down).

However, at least theoretically, it should not be too difficult to provide a different implementation of HttpRequester that could source block ranges from potentially multiple files, and fallback to downloading and caching an entire file if a ranged request failed. The work that would be required would largely be to decide how to chop up the input, lay that out as URIs and if that should be handled as a dynamic concern by a webserver or a static one (say, S3).

In order to achieve this, it would probably be best to embed the Verifier into the requester so that it can handle and respond to more cases internally (See BlockSourceBase).

The intent is that the use of Go's interfaces allows delegation of responsibility - the HttpRequester and BlockSourceBase should be almost entirely pluggable, and how you would get the information about the file splits could be an external concern.

[stkim1]

I appreciate your input. I've been digging and starting to draw diagrams to picture how the code is designed. It seems, though, writing test cases against possible failures, especially related to http connections, could render a feasible leverage to catch up the design in time and build the HTTP 1.0 fallback measure.

Coincidentally, you've stated that Network Error handling is one of the improvements you've sought for, and it seems to be the top priority to production readiness mentioned in #15.

I have had very pleasant experience from network simulator such as Network Link Conditioner, albeit only on OSX. I don't believe the very utility could be deployed on such test cases, but the notion of having artificial conditioner to stimulate network issues should stand valid for some degree.

In search of similar tools, I've encountered tylertreat/comcast and Shopify/toxiproxy.

Both projects are highly oriented toward CLI usage, but I think it should be possible to incorporate one of them into tests within affordable time window. I'll start building test cases, and make PRs. I hope you can save some time to review additional tests, and guide me to cover corners properly.