Closed JAndritsch closed 11 years ago
Well, yes, this is one way to do it (put the desired contenttype in the request for get*_signature/s), but what I did was put that into a setting on the backend and only pass it to mule-uploader (see here: https://github.com/cinely/mule-uploader/blob/master/templates/index.html#L28 ).
I hope this answers your questions. If you think that using your solution is better (and present some clear advantages), I'd be glad to change the code to reflect your way of thinking.
Also, If you're building a Sinatra backend, consider adding a pull request with it, so I can add it to the list of supported backends. It doesn't have to be perfect either, I'd fix it as needed.
Thanks for the feedback!
Based on your examples, this is not an issue with your code, but rather an issue that's isolated to my custom implementation.
With regards to sending along content_type to the backend, I can't really argue against one method over the other. The only reason I sent the content type to the backend from Mule was to allow uploads of multiple file types. I suppose it could just have defaulted to application/octet-stream as well. It's really a preference thing.
Also, I will be sure to submit a pull request for my Sinatra back end to you once I get the time to do it.
Thanks for your help!
Greetings!
It appears that the PHP and Python backend examples require a 'content type' to be present when generating a chunk signature, however the 'get_all_signatures' request seems to be missing that information (Uploader.prototype.get_all_signatures).
I discovered this issue when I implemented my own Sinatra (lightweight Ruby framework) backend that was based on your sample backends. My uploads were failing at first, and I was able to figure out that my signatures were getting generated with a 'nil' content type. Once I added 'content_type' to the query string for the get_all_signatures request, my uploads started working.