Max-size determination and storage algorithm to be hardened.

[MartijnR]

Needs to check regularly for the max-size that is supported by the server, and especially if the maxSize value stored in indexedDb is null for any reason.

It might be good to not store the default size in the db (if this is done currently - it might not be).

Investigate why max-size retrieval often fails (or maybe for certain OpenRosa servers?)

[MartijnR]

Also check if HEAD request to /submission passes credentials (Enketo Legacy doesn't).

[MartijnR]

That bug is not present in Enketo Express

[MartijnR]

#370

[ukanga]

Is this related to X-OpenRosa-Accept-Content-Length? ODK Collect usually checks this and sends the submission with attachments in batches, each batch is of a size less than the specified content length.
X-OpenRosa-Accept-Content-Length should be available in the head request of pretty much any OpenRosa FormSubmissionAPI.

[MartijnR]

Yes. Enketo checks this too.
On Jan 20, 2016 2:56 AM, "ukanga" [email protected] wrote:

Is this related to X-OpenRosa-Accept-Content-Length? ODK Collect usually
checks this and sends the submission with attachments in batches, each
batch is of a size less than the specified content length.
X-OpenRosa-Accept-Content-Length should be available in the head request
of pretty much any OpenRosa FormSubmissionAPI.

—
Reply to this email directly or view it on GitHub
#341 (comment)
.

Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

[ukanga]

Does enketo do the upload in batches?

[MartijnR]

Yes
On Jan 20, 2016 10:58 AM, "ukanga" [email protected] wrote:

Does enketo do the upload in batches?

—
Reply to this email directly or view it on GitHub
#341 (comment)
.

Revolutionizing data collection since 2012.

Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/

[MartijnR]

issues found (but no actual bugs):

• maxSize is stored in Db and used in offline-capable views (necessary for file input!). It is only updated when the formCache is refreshed. This seems to make sense. Maybe consider not storing a default size though, as it seems better to attempt to request it when it's missing. Figure out how the maxSize value actually gets stored though. Is it actually stored the first time a form is launched?
• the logic for previews to avoid requesting maxSize in connection.js is weird and wrong for e.g enke.to/preview/::abcd -> make this smarter, e.g. determine type of view (if settings.type === 'preview')
• let Enketo server not set a default size (in communicator.js), but return null or something
• file-manager.js also sets a default size. Not necessary?
• at least log an error to the console, if a response was received from Enketo server (= online) && Ona/KoBo did not include header or did not return a response or returned an invalid response.

[MartijnR]

The only 'bug' was the fact that under certain very rare circumstances the default max submission size gets stored in db and won't update until the form changes.

That rare circumstance is: the OpenRosa server does not serve the X-OpenRosa-Accept-Content-Length header (or does not return a response to HEAD /submission) at exactly the moment the form is cached (or re-cached).