You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using respond().withContentType("text/plain; charset=CP1250") I would expect that response encoding will be set automatically based on the content type.
The text was updated successfully, but these errors were encountered:
Right now the withContentType method is a shorthand version for withHeader("ContentType", value) and therefore doesn't parse the value at all. If you want to specify the encoding explicitly (and not use the UTF-8 default), you have to call the withEncoding method.
This allows to simulate a faulty server which claims the response is in a specific encoding (using the Content-Type header) however the body is in fact encoded using a different encoding. It is an edge case, definitely, but it may be handy.
Do you have any suggestions? Should Jadler support this edge case? Any ideas to make this more user friendly?
I agree with @jandudek. Som servers just behave badle, and id should be possibly to stub out such a server with jadler.
So if this should be implemented, it should somehow be made optional. This could be done by a making a overloaded version taking an ekstra boolean flag, or mayby an EnumSet if more switches like this is expected over time:
When using respond().withContentType("text/plain; charset=CP1250") I would expect that response encoding will be set automatically based on the content type.
The text was updated successfully, but these errors were encountered: