Meteor-Files: Session expired

Uploading files times out and throws an error in the .on(“end”) callback.

• when using ddp it happens with files ~10mb or bigger
• when using http as the transport it happens with files ~14mb or bigger
• Meteor@1.5.1 & ostrio:files@1.8.2 (with 1.9.3 it’s the same problem, but message of the error is non-existant)

Here’s client side log -

POST http://dan-vm:3000/cdn/storage/Files/__upload 500 (Internal Server Error) HTTP.call @ httpcall_client.js:189 UploadInstance.sendEOF @ client.coffee:524 emitEvent @ event-emitter.jsx:373 (anonymous) @ client.coffee:503 (anonymous) @ httpcall_client.js:83 (anonymous) @ underscore.js?hash=c…0189e39c665183c:794 xhr.onreadystatechange @ httpcall_client.js:172 XMLHttpRequest.send (async)
HTTP.call @ httpcall_client.js:189 UploadInstance.sendChunk @ client.coffee:485 emitEvent @ event-emitter.jsx:373 worker.onmessage @ client.coffee:715

Followed immediately by my console.error of the error returned by the callback of the upload end event:

Error: failed [500] {“error”:{“isClientSafe”:true,“error”:408,“reason”:“Can’t continue upload, session expired. Start upload again.”,“message”:“Can’t continue upload, session expired. Start upload again. [408]”,“errorType”:“Meteor.Error”}} at makeErrorByStatus (httpcall_common.js:13) at XMLHttpRequest.xhr.onreadystatechange (httpcall_client.js:170) (anonymous) @ manageFiles.js:222 emitEvent @ event-emitter.jsx:373 UploadInstance.end @ client.coffee:442 emitEvent @ event-emitter.jsx:373 (anonymous) @ client.coffee:538 (anonymous) @ httpcall_client.js:83 (anonymous) @ underscore.js?hash=cde485f60699ff9aced3305f70189e39c665183c:794 xhr.onreadystatechange @ httpcall_client.js:172 XMLHttpRequest.send (async) HTTP.call @ httpcall_client.js:189 UploadInstance.sendEOF @ client.coffee:524 emitEvent @ event-emitter.jsx:373 (anonymous) @ client.coffee:503 (anonymous) @ httpcall_client.js:83 (anonymous) @ underscore.js?hash=cde485f60699ff9aced3305f70189e39c665183c:794 xhr.onreadystatechange @ httpcall_client.js:172 XMLHttpRequest.send (async) HTTP.call @ httpcall_client.js:189 UploadInstance.sendChunk @ client.coffee:485 emitEvent @ event-emitter.jsx:373 worker.onmessage @ client.coffee:715

I am doing some pretty custom stuff as described in issue #505 - includes reading the file, converting to base64, getting workers to do RSA encryption, then returning the data to the main thread and feeding the encrypted data to the upload function. So it seems like the whole process just takes too long, more than 3 minutes for a 14mb file and maybe the http/ddp session expires, although not sure how the ddp meteor default session would expire since I’m still loged in, maybe just the sockjs(?).

Using 1.9.3, the latest version of the files package results in the following server side log:

[FilesCollection] [Upload] [HTTP] Exception: [TypeError: Cannot convert undefined or null to object]

While the client side logs look like this

httpcall_client.js:189 POST http://dan-vm:3000/cdn/storage/Files/__upload 500 (Internal Server Error)

and the console.error looks like

File upload error -> Error: failed [500] {“error”:{}} at makeErrorByStatus (httpcall_common.js:13) at XMLHttpRequest.xhr.onreadystatechange (httpcall_client.js:170)

The weird part is that I assume the file upload failed since I get an error. This doesn’t seem to be true though, the uploaded file actually gets to the server successfully as I can download it afterwards with no degradation whatsoever. The problem is that it might freak out the user and make it hard to distinguish between successful and unsuccessful uploads. I also need the document id given to the file as the post upload function triggered in .on("end") tries to link the file to another object - this obviously fails because the doc data doesn’t contain the _id. It does contain all the other file metadata though in 1.8.2, in 1.9.3 I get an object of this form for the document { error : {} }.

Any suggestions on what might be causing this ? I think having a way to extend the http request/response timeout might be the solution. I noticed that the constructor has a config.responseHeaders function that allows you to modify the headers - does that sound like the correct place to play with to see if I can get around it.

P.S. For some reason this was not happening a month or so ago - all uploads, even 20mb ones (the current maximum allowed) were succeeding without this happening.