[Akka-HTTP] How do I not specify the charset?

[Derek Wyatt]

Hi guys,

I've written a reverse-proxy with Akka-HTTP and I'm hitting a problem while trying to interact with an ASP.NET app.  The only interesting thing I can see is that without the proxy, the Content-Type is lacking a charset but the proxy adds charset=UTF-8.

I can't find a way to replicate that using Akka HTTP.  I think we can all agree that the addition of charset=UTF-8 is the right thing to do, but in this case it may be causing us a problem and I'd like to force it to look the same.  The best I've gotten so far is a definition where it has 'charset=', which isn't quite right.

Can this be done?

[Viktor Klang]

"The "charset" parameter is used with some media types to define the character set (section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value. See section 3.4.1 for compatibility problems."

https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7

--
Cheers,
√

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscribe@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Derek Wyatt]

I was able to verify that this is breaking the app in question, but not with Akka.  I merely added the charset to the request that was working, and it broke.

But I think I have a more fundamental problem: I can't see the raw request that came in from the client.  It, of course, is only represented using the Akka HTTP model and that model requires a charset for NonBinary ContentTypes.  So, if I wanted to try and force the outgoing request (to the server for which I am being a reverse-proxy) to match the incoming request in this regard, I wouldn't have enough information to know that I should do that.

Is there any way to get at the raw HTTP request so I can inspect it?  I think I need to see exactly how the client created it in the first place.

[Derek Wyatt]

I'm not arguing that Akka is doing the wrong thing.

But, I'm pretty screwed right now because significant functionality of the app for which I'm proxying is broken due to this and it's probably going to be my problem to fix :)  So, is there any way that I can hook into the parsing and rendering of the request in order to munge it into something that doesn't break this poorly behaving app?

On Tuesday, September 13, 2016 at 1:29:03 PM UTC-4, √ wrote:

"The "charset" parameter is used with some media types to define the character set (section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value. See section 3.4.1 for compatibility problems."

https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7

--
Cheers,
√

On Sep 13, 2016 18:58, "Derek Wyatt" <de...@derekwyatt.org> wrote:

Hi guys,

I've written a reverse-proxy with Akka-HTTP and I'm hitting a problem while trying to interact with an ASP.NET app.  The only interesting thing I can see is that without the proxy, the Content-Type is lacking a charset but the proxy adds charset=UTF-8.

I can't find a way to replicate that using Akka HTTP.  I think we can all agree that the addition of charset=UTF-8 is the right thing to do, but in this case it may be causing us a problem and I'd like to force it to look the same.  The best I've gotten so far is a definition where it has 'charset=', which isn't quite right.

Can this be done?

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.

[Derek Wyatt]

We have been able to see it work, if we put the charset between the multipart/form-data and the boundary.  i.e.

Content-Type: multipart/form-data; charset=utf-8; boundary=----some-nonsense-here

Which should reasonably work for everyone, including this busted app.  I know that it messes with the rendering a little bit (i.e. the MediaType is rendered, and then the charset is rendered), but would you guys consider a PR with that change?

[André]

Hi Derek,

to get an exact view of the raw incoming request I'd suggest to consult Wireshark. Akka's logRequest directive can show slightly different/adapted data.

HTH

André