Playframework: akka-http provides wrong Content-Disposition in uploads

Created on 10 Aug 2017  ·  4Comments  ·  Source: playframework/playframework

Play Version (2.5.x / etc)

2.6.2, using akka-http

API (Scala / Java / Neither / Both)

Scala (but I imagine Both)

Expected Behavior

Please describe the expected behavior of the issue, starting from the first action.

  1. Send a POST request with the header: Content-Disposition:attachment; filename*=UTF-8''Roget%27s%20Thesaurus.pdf
  2. In your handler, dump the uploaded headers: System.err.println(requestHeader.headers)

You should see Content-Disposition as attachment; filename*=UTF-8''Roget%27s%20Thesaurus.pdf

Actual Behavior

The Content-Disposition header is attachment; filename="UTF-8''Roget%27s%20Thesaurus.pdf"

The problem: akka-http adds "" and removes *. https://github.com/akka/akka-http/issues/1240 and https://github.com/akka/akka-http/pull/695 go into why.

So there are two problems, really:

  1. The value is wrong -- akka-http converted it in a way that can't be correctly reversed.
  2. Netty doesn't do this erroneous conversion, so switching between Netty and akka-http causes an unexpected change in behavior.
defect

Most helpful comment

@marconilanna Thanks for the fix! Yes, this works for us and I've reverted our icky workaround.

All 4 comments

Yes akka-http has problems both parsing and rendering header parameters with extended charsets.

We were able to write a workaround when sending files (see #7501) since Play has access to the raw filename string when it sends a response. However Play won't be able to support uploads with encoded filenames until https://github.com/akka/akka-http/issues/1240 is fixed, since akka-http will change the filename before Play receives it.

Tagged as 2.6.8 because this is an Akka HTTP backend related regression that we should fix on the 2.6.x branch.

@adamhooper,

There is a fix for this issue on Play 2.6.13. Could you please try this new version and confirm it is working for you?

I'm closing it now, but if the fix doesn't work, we can reopen this issue with the additional information.

Thanks!

@marconilanna Thanks for the fix! Yes, this works for us and I've reverted our icky workaround.

Was this page helpful?
0 / 5 - 0 ratings