Uploading a file from dropbox with the letter É results in a 404

[sellingsolutions]

Download the PDF attached to this issue and upload it to your dropbox account.
A-40_1-210_PLAN_10_ENTRÉPLAN_TRH_2.PDF

Steps to re-produce:
Login to dropbox via FPPicker 5.1.2 on an iPad Air 2 iOS 9.2 Simulator
Press on the PDF specified above

You should now see the error message alert view displaying:
"Internet Connection"
"Request failed: not found (404)"

[pJes2]

Actually, I cannot even change the name of the file on Dropbox to "A-40_1-210_PLAN_10_ENTRÉPLAN_TRH_2" (see http://cl.ly/3a0k0c2d1U0g)

EDIT:
Managed to reproduce the issue with other set of "special" characters - I'll try to dig some more

[sellingsolutions]

Yeah this is consistent with all Swedish characters as well

[msmollin]

+1 to this. ñ is my current problem as I have Spanish-speaking users.

For what it's worth, we encountered this bug when upgrading from 3.2.9 -> 5.1.4. Our current production application is still using 3.2.9 and does not have this problem.

[msmollin]

So I spent about 20 minutes diagnosing the problem, and as suspected, it's a double-encoding issue.

For a given object:
{ bytes = 141786; "display_name" = "Character Sheet with \U00f1.pdf"; filename = "Character Sheet with \U00f1.pdf"; "is_dir" = 0; "link_path" = "/Dropbox/Character%20Sheet%20with%20%C3%B1.pdf"; mimetype = "application/pdf"; modified = ""; size = "138.5 KB"; "thumb_exists" = 0; thumbnail = "https://d2hbo3cbwd28c.cloudfront.net/048ba34/img/thumbnails/file.png"; }

The problem starts here:
https://github.com/Ink/ios-picker/blob/develop/FPPicker/Shared/FPLibrary.m#L24

The code asks for a request for the given link_path which, as we can see above, has a UTF-8 ñ that's already been html-encoded once.

Then we move into:
https://github.com/Ink/ios-picker/blob/develop/FPPicker/Shared/FPLibrary.m#L292

Where, as linked, the code appends link_path, now called loadPath, into a NSURLComponent, which, upon printing said component from LLDB yields:

Printing description of urlComponents:
<NSURLComponents 0x7e84d2a0> {scheme = https, user = (null), password = (null), host = dialog.filepicker.io, port = (null), path = /api/path/Dropbox/Character%2520Sheet%2520with%2520%25C3%25B1.pdf, query = (null), fragment = (null)}

Which yields a double-encoded path variable. %2520 is the encoded form of %20 as the % symbol encodes to %25.

My suggestion here is, instead of setting the .path property, to instead use the .percentEncodedPath property. That way the path string will be assumed to be percent-encoded from the get-go and won't get double-encoded. See docs here: https://developer.apple.com/library/ios/documentation/Foundation/Reference/NSURLComponents_class/#//apple_ref/occ/instp/NSURLComponents/percentEncodedPath

The issue here naturally is I don't know how that affects the assumptions made about this method. If the expectation is that your loadPath will always be percent-encoded, then I believe this is a safe change. However, if loadPath is ever not percent encoded, then things will break.

[msmollin]

I've opened #126 to fix this problem. However, this has highlighted what I can only determine to be a server-side issue wherein the server deforms non-ASCII unicode characters where ñ becomes ñ

Diagnosis:
Starting in FPSourceController.m @ Line 1209 (https://github.com/Ink/ios-picker/blob/develop/FPPicker/Platforms/iOS/FPSourceController.m#L1209) we see the initial request being built up. Printing out mediaInfo.filename yields our currently correct file name.
(lldb) po mediaInfo.filename Character Sheet with ñ.pdf

Next we land in our friend FPLibrary, which in my branch has now been updated to safely allow for certain methods to request URL encoding on their load path. FPLibrary goes through all its normal routines for building up a mutable URL request, which at the end of it all produces output that looks like this:

(lldb) po mRequest
<NSMutableURLRequest: 0x79ee7990> { URL: https://dialog.filepicker.io/api/path/Dropbox/Character%20Sheet%20with%20%C3%B1.pdf?<snip> }

The snip is so to avoid posting my API keys ;-)
However that URL decodes correctly into https://dialog.filepicker.io/api/path/Dropbox/Character Sheet with ñ.pdf? so all is still good.

It's upon executing our success block here - https://github.com/Ink/ios-picker/blob/develop/FPPicker/Shared/FPLibrary.m#L37 - that things go awry. The file name the library is using is coming from the headers. Printing out out that headers object looks like this:

(lldb) po headers
{
    "Content-Disposition" = "inline; filename=\"Character Sheet with \U00c3\U00b1.pdf\"";
    "Content-Length" = 141786;
    "Content-Type" = "application/pdf";
    Date = "Fri, 04 Mar 2016 13:54:53 GMT";
    P3P = "CP=\"OTI DSP COR ADM DEV TAIo PSA PSD IVAi IVDi CONi HIS OUR IND CNT COM INT NAV\"";
    Server = nginx;
    "Set-Cookie" = "session=\"pcrVNGsKjzMFex8SpYxKR8u+5is=?_expires=STE0NTk3NzgwOTMKLg==&_fresh=STAwCi4=&_id=UydceGU0XHg3Zlx4YzYuOlx4YzlceGVlXG45XHg5Zlx4OTBrXHhlN1x4ODAvXHhkOScKcDEKLg==&_permanent=STAxCi4=&cmux_rd=Ti4=&recent_path=UycvRHJvcGJveC8nCnAxCi4=&user_auth_id=STYwODQwMjUKLg==\"; Domain=dialog.filepicker.io; expires=Mon, 04-Apr-2016 13:54:53 GMT; Path=/; HttpOnly";
    "X-Data-Filename" = "Character Sheet with \U00c3\U00b1.pdf";
    "X-Data-URL" = "https://www.filepicker.io/api/file/CdLph9IuQNCWxE4KSEG0";
    "X-File-Name" = "Character Sheet with \U00c3\U00b1.pdf";
    "X-File-Size" = 141786;
    "X-No-Compress" = true;
}

As you can see, X-Data-Filename is clearly wrong, as it now consists of two special characters versus our previous 1.

So, I feel my change is safe to use, but there's a server-side issue that could need resolving. What's confusing is when looking in the Assets part of the developer portal, the name is correctly shown:

I'm at a loss as to what the issue could be then.

[msmollin]

Going to gently bump this issue - we're gonna move forward with releasing with our fix in place I think, but I'd really like Filepicker to chime in on this.