-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error binding should include response / 400 MalformedPOSTRequest on S3 #763
Comments
The problem here is that depending on the runtime you might not even get a response body when status code is error. Are you on stable 1.x branch? Does Amazon log only status, or the whole erroneous POST body? |
To be honest I'm a bit worried that the response body will actually be empty anyway :(. I'm using 1.5.7 at the moment which I pushed out today. I'll keep an eye to see if any new failures come in today. Not sure about the Amazon logs to be honest, it would be nice to see the actually post body in this instance from their side. Their logs appear to be a pretty standard combined log format. I'll do some more research. |
I'm asking because 400 MalformedPOSTRequest is already kinda informative and there could be nothing else in the response anyway. What can help, could be an actual body of such malformed request. From Error Responses:
Could you post Plupload config that you use? |
Thanks for your time on this, I hope it is an interesting puzzle. This is probably overkill because we make changes to the upload settings as we go, but I'll explain the process we take in case anything we're doing along the way rings any bells. We initialize our uploader to begin with for the most part single queue, filtering a few file types, allowing multiselection, etc. In order to upload to S3 in the correct location we create an asset on our server and pass back the relavent S3 policy pointing to the correct key say 'assets/000/000/001/original.wav'. We initialize the upload and make an ajax call in 'BeforeUpload' to create the asset on our server, this returns an asset object and S3 policy as JSON. We overwrite the name of the uploading file 'name' and 'Filename' with something like 'asset_001' because non-ascii UTF-8 characters get messed up being passed as a JSON string (and subsequently no longer match the S3 policy) and we have to supply both 'name' and 'Filename' in the post and the S3 policy because of Flash on IE seems to post both which blocked us for a while. We set the additional parameters for the S3 policy and call up.trigger('UploadFile', file) In terms of grabbing the post body it seems impossible to log on Amazon, it would be pretty huge anyway, and only the uploader itself will be able give us the body its posting to S3. I wish we could replicate this ourselves as I'd have much more to go on.
|
I hope coffeescript isn't a pain. |
No chunking, no client-resizing... hm... seems like Plupload is using native upload methods for both html5, and flash. For some reason though I think this should be flash failing. Anyway, this is bad, as default upload methods can't be affected in any way... Do you got any additional details, like the browser type and version where failure was detected? or have the file that failed? Do you know if failed file ever uploaded successfully afterwards? |
I've been using plupload for a few weeks now and I've managed to hook it up to upload our files directly to S3 which is great. However we realised that some files are not being saved on S3 the response from Amazon from their logs shows for some clients 400 MalformedPOSTRequest. This is probably less than 1% but that's still significant.
The problem is that if users upload files and that fails we have no way of knowing (without replicating the error ourselves with the exact file and exact set up as them, which is tricky and we haven't managed to replicate an error even once). My next thought was we could post the error response to our server everytime this happens so we could debug the error without having to get the user to investigate their JS console looking for it.
Forcing an error from our side we can see that the response body is not included in the error which would be really handy. 'HTTP Error' is all we get.
Object {code: -200, message: "HTTP Error.", file: g.File, status: 403}
The 'FileUploaded' callback supports the response
uploader.bind 'FileUploaded', (up, file, response) ->
However, 'Error' does not.
uploader.bind 'Error', (up, error) ->
While this might not solve our problem we'd like to see if there is a more detailed error in the response body from Amazon and if that points to a further problem within plupload.
The text was updated successfully, but these errors were encountered: