I've encountered a tricky situation trying to develop a loader that will take in a resource that has a fallback URL in case of 404 errors. Here goes:
I use Firefox 20.1 with Shockwave Flash debug pluggin version 11.5.502.146.
The server is Ubuntu 12 running Apache 2.
Intentionally setting a bogus URL on the resource for a ImageElement, yields an argument error.
Inspecting the code at runtime show that the error is thrown from LoadTrait.setBytesLoaded() because the bytesLoaded value is greater than the bytesTotal... (333 and 270 respectively)
Inspecting the server logs, what goes through the wire and what a standard client (Curl) sees, it turns out tha 270 is the size of the gziped 404 payload and 333 is the deflated size.
Is this a bug or is it a normal behaviour?
In any case it makes my application relatively unforgiving when it comes to the exactitude of an image resource. I mean I can't be wrong with the poster frame's URL or its availability on the server or my player kills itself...
I propose modifying the conditional statement in LoadTrait on line 282 like such:
if (isNaN(value) || value < 0) //if (isNaN(value) || value > bytesTotal || value < 0)
throw new ArgumentError(OSMFStrings.getString(OSMFStrings.INVALID_PARAM));
The interesting thing is that this error is not thrown in Chrome. I haven't tried IE, and quite frankly, I won't!
Anybody able to reproduce this behaviour?
In IE (8-11), I am still able to reproduce with Adobe's OSMF-based Strobe player 188.8.131.529 which I believe is OSMF 2.0.2494.
We're seeing it on a service which returns an xml-formatted error if the poster image is not authorized. I stubbed out a minimal test case with the PHP below.
The response codes doesn't matter as long as it's non-200. If the xml header is present and the body has any length, then the ArgumentError occurs. Doesn't happen with a "text/plain" response. =/ Does not occur if I disable mod_deflate (gzip).
header('HTTP/1.0 403 Forbidden');