-
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
html5 firefox 7.01 and chromium 12 #398
Comments
Looks like they documented the change here: https://developer.mozilla.org/en/DOM/XMLHttpRequest/FormData#Gecko_notes
|
'Prior to' I'm using FF 7.0 so it shouldn't be happening right? On 10/04/2011 10:18 PM, Charles Capps wrote:
|
filename="blob" is expected behavior, why do you think it is lost? This should be happening only when you have chunking enabled, so every chunk will be sent this way. The problem with Geckos prior to 7 was that they were sending empty string in filename (like filename=""), which caused some servers to not interpret this properly, but filename="blob" is ok. You shouldn't have any problems with this. If you have some, then maybe describe your usage case in a bit more detail. |
Chromium 12.0 should not be having any problems at all, so - yes, something odd happens. Please provide more details - config, your code, your expectations. |
I'm having the same problem on Chrome 14 using html5. It still works with flash. The problem is the 'name' in $_REQUEST is returning a Blob.... name instead of the actual filename. So what you end up with is a separate Blob file for each chunk instead of having each Blob file appended to the single server-side file with the actual filename. // Get parameters |
@chrisuae name in $_REQUEST, or name in $_FILES?.. |
Chrome 12, Chrome 14... I'm using Chrome 15... who said IE is nightmare? |
Ok, here's a var dump $_POST: $_FILES: Basically the configuration doesn't matter I get the same problem on: http://www.plupload.com/example_all_runtimes.php My expectations, as it used to work, is that |
I'm afraid there is no way around this. I wish there was, but there's none. In case you manage to find one, let us know. We are open to suggestions. Setting filename as blob when sending chunks is actually current W3C recommendation. There's a plan to make it possible to pass filename as third parameter. But I've not seen any support for this in current browsers. By now you should not rely on $_FILES[...][name]. Use $_REQUEST['name']. |
On 10/05/2011 09:51 PM, Davit Barbakadze wrote:
|
In your case I see that you got unique_names option set to true. That's why you get those cryptic filenames in |
On 10/05/2011 10:08 PM, Davit Barbakadze wrote:
|
blob filename issue: |
I had the same problem it was the resize option. remove that from cofiguration and should be fine |
Blob (+ some gibberish) is a normal thing if you are awaiting filename from $_FILES['file']['name'], that's why we send original file name with every chunk in $_REQUEST['name']. |
Any update on this? Using PLUpload with wordpress/gravity forms implementation. Try to figure out how to get it to take the original filename, and not blob. From upload.php:
Here are my parameters:
|
i have done it by adding filename into each chunk using "BeforeChunkUpload" method , here is my code init:{
BeforeChunkUpload: function(uploader, file, post, currentBlob, currentOffset) {
currentBlob.name=file.name;
},
}, then you have the filename in each chunk instead of that shit "blob" name. |
When I upload a file in multipart mode using the HTML 5 runtime, the filename is lost and the browsers just sends:
-----------------------------1117779921282589049853871300 Content-Disposition: form-data; name="file"; filename="blob"
This problem occurs when using FireFox 7.01 as well as Chromium 12.0 although I get hash appended to the filename e.g.: "blob891902399ef9a9b1123de9a". I tried it on a windows VM image and it also gave me 'blob' as filename. I also uploaded a file on: http://www.plupload.com/example_all_runtimes.php and noticed filename="blob" in the headers aswell.
I'm running ubuntu 11.04 64bit
The text was updated successfully, but these errors were encountered: