Filename of WAFile created in (Zinc) server adaptor is not decoded #836

Closed
GoogleCodeExporter opened this Issue Mar 25, 2015 · 7 comments

Comments

Projects
None yet
3 participants
What steps will reproduce the problem?
1. Use the Zinc Adaptor in Pharo (I tested with this one, but GemStone FastCGI 
also has this issue)
2. Upload a file with a filename using characters with codepoint > 256 with a 
modern browser and handle it in a Seaside file upload callback

What is the expected output? What do you see instead?
I expect the filename to be decoded. Now I see a string of the bytes in UTF8 
encoding.
The filename is part of the Content-Disposition header, which is UTF8 encoded 
by modern browsers [1][2].

[1] 
http://www.bennadel.com/blog/2591-embedding-foreign-characters-in-your-content-d
isposition-filename-header.htm
[2] http://greenbytes.de/tech/tc2231/

Proposed fix is the utf8 decoding of the filename when it is passed to the 
WAFile instance. I am currently assuming browsers always use UTF8 here, 
regardless of the encoding of the body (to be verified). Otherwise, 'self 
codec' should be used instead of the utf8 codec.

convertMultipartFileField: part  
    | file |
    (file := WAFile new)
        fileName: ((GRCodec forEncoding: 'utf-8') decode: part fileName);
        contentType: part contentType printString;
        contents: part contents.
    ^ file

Original issue reported on code.google.com by jo...@yesplan.be on 7 Nov 2014 at 2:59

Ok, because the mimeparts are part of the body of the request, they are encoded 
by the browser. The links I refer to above are not relevant as they concern the 
http headers, not the mimepart headers. So, the correct code for this fix in 
the Zinc Adaptor is:

convertMultipartFileField: part  
    | file |
    (file := WAFile new)
        fileName: (self codec decode: part fileName);
        contentType: part contentType printString;
        contents: part contents.
    ^ file

Original comment by jo...@yesplan.be on 14 Nov 2014 at 6:55

  • Added labels: ****
  • Removed labels: ****

Original comment by jo...@yesplan.be on 14 Nov 2014 at 6:55

  • Changed state: Started
  • Added labels: ****
  • Removed labels: ****
And it seems I should have properly followed this discussion [1] as it's 
exactly that issue.

[1] http://forum.world.st/File-upload-encoding-issue-td4783446.html

Original comment by jo...@yesplan.be on 15 Nov 2014 at 11:38

  • Added labels: ****
  • Removed labels: ****

The solution doesn't work for all characters,

(GRCodec forEncoding: 'utf-8') decode: 'hellò.doc'.
(GRCodec forEncoding: 'utf-8') decode: 'hellò.doc'.
(GRCodec forEncoding: 'utf-8') decode: 'í.txt'.

and it raises "Invalid utf8 input detected" error! (Firefox 41 under Linux)

fileName decoding in ZnZincServerAdaptor>>convertMultipartFileField: should be removed, because it's already present in ZnMimePart>>fileName (with timestamp 10/10/2014), was added in Zinc-Seaside-JohanBrichau.43 (14 November 2014)

@jbrichau jbrichau self-assigned this Nov 11, 2015

@jbrichau jbrichau added this to the 3.2 milestone Nov 11, 2015

@jbrichau jbrichau modified the milestones: 3.3, 3.2 May 5, 2016

Owner

jbrichau commented Jun 25, 2016

Somehow, there has been a confusion because I had a different package for the same package version of Zinc-Seaside in my package cache. Moreover, it only seems to crash in Safari and Firefox and not in Chrome... See more in this thread: http://lists.squeakfoundation.org/pipermail/seaside/2016-June/032248.html

It should be fixed once Sven publishes the Zinc-Seaside-JohanBrichau.44 package and I updated the ConfigurationOfSeaside3 to reference it.

@jbrichau jbrichau removed this from the 3.3 milestone Jul 3, 2016

Owner

jbrichau commented Jul 3, 2016

Fixed 3.2.1 and 3.1.6 loads.

@jbrichau jbrichau closed this Jul 3, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment