On Tue, Jun 3, 2014 at 1:05 PM, Nikita Karetnikov
Thanks, but it fails when a user tries to access ‘/view’ before uploading a file.
Yeah, I didn't bother to implement error handling.
Also, I want the file to be available only at ‘/view’.
The version I provided meets that requirement for viewing the file. Perhaps you also want the the POST address to be /view? Ultimately, you need three end points: 1. a url to GET the file 2. a url to POST the file 3. a url that shows the form How you arrange that depends a lot on your design goals and requirements. If you only allow the user to upload the file once, then you could have: 1. GET /view, shows the form if the file does not yet exist 2. POST /view handles the file upload 3. GET /view shows the file if it has been uploaded This does not provide a way to view the form again once the file has been uploaded. You could also do something like; 1. GET /file/upload_form, shows upload form 2. POST /file, handles submission 3. GET /file shows file if it exists, or redirects to /file/upload_form Or.. whatever you want.
I’ve attached a version that’s based on yours, can it be further improved? For instance, is there a need for ‘seeOther’?
After the file is upload -- you need to return some sort of Response to the user. One logical choice is to redirect to the client to GET the resource that was just uploaded. In theory, at the end of handleUpload you could call readFile+output directly to show the file. But if the user then refreshes the page, it will attempt to POST the data again. If you have the redirect in there, then when they reload the page, it will simply perform the GET request again. As for 'improving' the code -- I think it mostly comes down to personal taste at this point. - jeremy