Missing quotes from values

[bre7]

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]

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

[bre7]

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]

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]

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]

@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]

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