Fix HTTP error handling in AICC packages
February 1, 2018 12:00 AM
Hi.
So today, one of my courses threw up an error dialog trying to navigate to the next page (see attachment). The message is "no HTTP support" with title bar text "trivantis-titlemgr-aicc.js".
Relevant lines of the file are:
if( httpReq.status != 200 ){
trivAlert( "HTTPCOMMERR", "trivantis-titlemgr-aicc.js", 'no HTTP support ' + httpReq.statusText );
return;
}
This is wrong on several levels. For one, the message is simply false. The problem is not a lack of HTTP support, it's that a single message was lost in the network somewhere. Since this happened on page 4 of the course, obviously the server support HTTP. I have no idea what it's even supposed to mean.
I used to design software, and a basic rule is that error messages should help the program's user fix the error (even if just by saying "Call support and tell them foo."). Why can't the JavaScript actually parse (for instance) a 404 error and say, "There is a link in the course to a page that does not exist. Please contact the course developer and tell them the error occurred on page bar trying to link to page baz."? A generic error for all HTTP codes except 200 just isn't that useful.
In this case, nothing at all was returned, or rather received by the browser. Why can't the course retry the connection instead of giving up and sending a useless error message, when the connection completely fails to complete? I'd even say, retry a couple of times before giving up. Not everyone has the luxury of reliable, high-bandwidth, low-latency connections, folks.
Thanks.
Discussion (1)
Thank you for pointing this out.
I believe this was something we inherited from a sample AICC wrapper back in the early 2000s.
We will get this written up to improve the retry handling and error reporting across our AICC and SCORM support files.
- Joe
Discussions have been disabled for this post