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
http_server uploaded file handling #14303
Comments
Set owner to @skabet. |
Hi Terry, You are right, in most cases with file uploads, it's the raw binary one wants to access. What if we do the following:
Regarding the filename, I think we should do a test and see what the different browsers upload. if we can hit a 90% success rate with some default encoding, that could be the way to go. |
I just tried with both chrome and Windows, and I get the following: With Without I think it's fine to use utf8-decoding for filenames. |
This comment was originally written by TerryMit...@gmail.com I confirmed it on my Windows Vista using following HTML text: 001 <!DOCTYPE html> If line 005 or 010 exists, Chrome, Firefox and Safari send filenames with multi-byte characters as UTF-8. Otherwise, such filenames are transmitted as Shit_JIS characters (one of most popular Japanese character encodings). Regardless of existence of line 005 or 010, IE sends them as UTF-8. I agree to use UTF-8 decoding (current implementation uses ISO-8859-1 decoding) for filenames. It’s common to add line 005 for such applications. |
Hi What do you think about the following API? /** /** /** /** /** /** /** /** /** /** cc @sethladd. |
Thanks! I like how HttpRequestBody implements HttpRequest now. Also, I like how I can control how I get the body (json, text, etc) because sometimes a content-type is not set on the request. |
This comment was originally written by TerryMit...@gmail.com I think this will give us more flexible POST body data handling. |
Removed Library-HttpServer label. |
This issue has been moved to dart-archive/http_server#11. |
This issue was originally filed by TerryMit...@gmail.com
Current http_body implementation decodes / parses HttpBodyFileUpload.content based upon the Content-Type header of the part.
However, file server applications need raw uploaded file data. Such applications save received files into their file system with no modification. I think we need a switch to disable decoding / parsing for all content types and just return type List<int> object as HttpBodyFileUpload.content.
Another solution would be to return simply List<int> for all uploaded files. I am not sure how much the impact of this on other kinds of applications. However, when a .json file was uploaded from HTML form, IE sends it as “Content-Type: text/plain” and Chrome, Firefox and Safari send it as “Content-Type: application/octet-stream” (I don’t know why). In any case, .json files uploaded through HTML form will never be parsed.
Regarding to the filename with multibyte characters, although Windows uses UTF-8, I think it might be safe to keep LATIN1 decoding. I am not familiar with other file systems. We can retrieve it using UTF8.decode(LATIN1.encode(part.filename)) with Windows, assuming that the LATIN1.decode(bytes) simply generates a String that has the same byte character to corresponding byte of bytes.
The text was updated successfully, but these errors were encountered: