Detailed HTTP Error Codes in Error Callback

[laberning]

Especially for Error Code 2, "CONNECTION_ERR" it would be very handy to also pass the HTTP-Errorcode back to the JavaScript-App.

I.e. an Application might treat a HTTP_NOT_MODIFIED differently from a HTTP_NOT_FOUND.

[imhotep]

Do you ever get a description associated with that CONNECTION_ERR ? If so, what is it ?

[laberning]

Thanks for looking into this.

The problem that I'm currently experiencing here is the following with creating a content update mechanism:

I have a content providing server that generates the ZIP file. This file is versioned (i.e. the zip-file contains a file "version" that identifies the current version of the content on the device).

If I pull the content via contentsync, I attach this version to the src-url (i.e. http://contentserver/contentfile.zip?contentversion=3).

In case the server has newer content available, it would generate a delta-update and pass that to the client (which is then merged with the existing content).

In case the server does not have newer content, it would pass back a HTTP-Error-Code HTTP_NOT_MODIFIED. This basically identifies "Hey client, you have the newest content version already, go on and show it to the user". If I see it correctly, the current Contentsync-API does not allow me to differentiate between the different HTTP-Status-Codes and instead just delivers a "CONNECTION_ERR" code via the Error-Callback.

In this particular case (Android implementation) it would:

sendErrorMessage("Resource not modified: " + source, CONNECTION_ERROR, callbackContext);

but the sendErrorMessage would only pass the Error-Type back to the callbackContext.

My proposal would be to pass some more information back to the callbackContext, i.e. HTTP-Statuscodes, if it is a CONNECTION_ERROR. Basically something similar to the first parameter of sendErrorMessage, but in a machine interpretable way (not localized) and delivered via the callback.

[imhotep]

@lberning I understand. We'd have to change the format of the plugin error. Right now we only return one of the following:

INVALID_URL_ERR,
CONNECTION_ERR,
UNZIP_ERR,
LOCAL_ERR

This would break some existing apps that rely on these error code. We could have an error object that includes the HTTP response:

{
   httpResponseCode: 404
   errorCode: CONNECTION_ERROR
   message: "Not Found"
}

I am happy to change it. I will discuss this with the other contributors.

[mwbrooks]

Great suggestion @lberning!

I agree with @imhotep. This is a really nice improvement to the current error callback information. Since it's a breaking change, we would need to bump the major version to ensure that people do not upgrade and break their apps.