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

Missing quotes from values #22

Closed
bre7 opened this Issue Apr 17, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@bre7
Copy link
Contributor

bre7 commented Apr 17, 2018

Missing quotes in values other than encoded file content. Interesting discussion in akka/akka-http#386 (includes spec requirements as well as browser compatibility comments)

E.g:

--BOUNDARY
Content-Disposition: form-data; filename=test.pdf; name=data
Content-Type: application/pdf

%PDF-1.3
...
@tanner0101

This comment has been minimized.

Copy link
Member

tanner0101 commented Apr 17, 2018

can you clarify what you mean by this? Maybe an expected vs. actual example.

@bre7

This comment has been minimized.

Copy link
Contributor Author

bre7 commented Apr 17, 2018

Expected:

--BOUNDARY
Content-Disposition: form-data; name="data"; filename="test.pdf"
Content-Type: application/pdf

%PDF-1.3
...

Actual result:

--BOUNDARY
Content-Disposition: form-data; filename=test.pdf; name=data
Content-Type: application/pdf

%PDF-1.3
...
@tanner0101

This comment has been minimized.

Copy link
Member

tanner0101 commented Apr 20, 2018

Ah, I see. The relevant code is here: https://github.com/vapor/core/blob/master/Sources/Core/HeaderValue.swift#L60-L66

The question is: do we need quotes?

@bre7

This comment has been minimized.

Copy link
Contributor Author

bre7 commented Apr 20, 2018

I'm not 100% sure, I bet most (if not all) modern browsers can handle it. Though what would happen with filenames with spaces ?

I read the issue I linked before and there are a bunch of RFCs linked inside it.

Original RFC 2616 and newer RFC 6266 give different grammars / recommendations whether
to quote parameter values. It seems that current software is still confused about what to accept and what not.

Appendix A of RFC 6266 says:

  RFC 2616 only allows "quoted-string" for the filename parameter.
  This would be an exceptional parameter syntax, and also doesn't
  reflect actual use.

This doesn't mean that quotes are strictly required, so, given the reports of breakage
without quotes, let's force quotes for now for Content-Disposition parameters.

https://stackoverflow.com/a/6745788/2124535... As always, browser compatibility is to blame 😠 Excerpt:

I have found that modern browsers support rfc5987, which allows utf-8 encoding, percentage encoded (url-encoded). Then Naïve file.txt becomes:

Content-Disposition: attachment; filename*=UTF-8''Na%C3%AFve%20file.txt

Safari (5) does not support this. Instead you should use the Safari standard of writing the file name directly in your utf-8 encoded header:

Content-Disposition: attachment; filename=Naïve file.txt

IE8 and older don't support it either and you need to use the IE standard of utf-8 encoding, percentage encoded:

Content-Disposition: attachment; filename=Na%C3%AFve%20file.txt

@Cellane

This comment has been minimized.

Copy link

Cellane commented May 8, 2018

@tanner0101 After yesterday’s and today’s experience with trying to get multipart POST request get accepted by Cloudinary’s servers, I’m afraid that yes, we totally need this.

Thanks to your help on Discord, I was able to write a code that would create almost the same request in my Vapor app as Cloudinary’s libraries (in many different languages and platforms, from Ruby through Node.js, PHP🤢, Django to native iOS) – except Cloudinary’s requests from their Ruby library would get accepted and Vapor’s almost equivalent request wouldn’t.

After capturing both requests in Charles proxy, it boiled down to one single difference between these two: Ruby version wrapped all values in quotation marks, Vapor didn’t. So I tried doing something really ugly with CodingKeys to get the quotation marks to show up and suddenly – the very same request gets accepted this time.

So if I may, I’d vote 100% for having values wrapped in quotation marks. It’s not only about browser compatibility but also about compatibility with other servers – true, it’s not the most common use case for most Vapor apps, but it may be relevant from time to time.

@Cellane

This comment has been minimized.

Copy link

Cellane commented May 14, 2018

Closing as this was resolved in vapor/core#144 and vapor/vapor#1668. Thank you so much!

@Cellane Cellane closed this May 14, 2018

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