Thank you for reaching out to us. Without the concrete URL, it is quite hard to evaluate your problem. But I had a peek at the code where your error is being raised and this seems to be a status code standardization problem as they have come up before for the
"partial get response (206) missing" is being raised when a response header contains the
content-range field but does not have the status code
206 (I agree, the error message is a bit misleading, as it indicates the opposite). So, without any concrete URL to test things, I would assume that your URL returns a status code other than
206, but still uses the
content-range field, which our
Url implementation then finds and responds to with its a bit cryptic error message.
We had a similar topic for error messages some while ago, with the central question being: What status codes are allowed when? In the error case it was that some websites send content although they return a status code
404. There is unfortunately no binding standard definition for status codes and their usage. Browsers, especially the large ones, have become exceptionally good at making the best out of such ambiguous responses. Our
Url type is much more bare bones in this regard. I could try to get this fixed, I however doubt that I will find a developer who is motivated to do so, because of the unbound nature of the problem. To avoid ambiguity: I will bring this up internally, but I am not optimistic for us fixing this.
You yourself could try to:
- Analyze how the browser is requesting the data. You are not setting up any request headers in your example. Setting the right flags could let the server behave differently (the Plugin Café thread linked above also contains examples for that).
- Setup the response header of your request, so that you can see what is actually going on.
- Try using
maxon::FileUtilities::ReadFileToMemory(webFile, data) instead of