servant-client requires charset in Accept PlainText

[bergmark]

The current implementation is

instance Accept PlainText where
    contentType _ = "text" M.// "plain" M./: ("charset", "utf-8")

Trying to parse text/plain yields UnsupportedContentType text/plain

One API I'm calling does not specify the charset so I can't use PlainText, but this does the job:

data PT
instance Accept PT where
  contentType _ = "text" M.// "plain"

The workaround is simple, but could/should the charset be made optional?

[phadej]

The API backend returns just Content-Type: text/plain without ; charset=utf-8?

We could assume that the text/plain without content-type is UTF8 like in
http://hackage.haskell.org/package/servant-0.14/docs/src/Servant-API-ContentTypes.html#line-142 but then APIs returning Full-Latin-1 (which is invalid UTF-8) would fail. @haskell-servant/maintainers opinions?

If we'd accept that change, I'd especially like to see a test (and a disclaimer in the docs) that the failure actually happens. (FWIW, browsers try to guess the encoding, I think, I don't like having guessing in servant).

[alpmestan]

I agree with @phadej. One thing I've thought about before is whether it'd be worth it to introduce some dedicated machinery to allow users to specify/override the charset, e.g data Charset (charset :: Symbol) (contentType :: *), along with instance (Accept ct, KnownSymbol charset) => Accept (Charset charset ct) where ....

[bergmark]

The API backend returns just Content-Type: text/plain without ; charset=utf-8?

Right

[phadej]

#366 (saving you a click: https://gist.github.com/phadej/af8ce4b8b3dece6e8a4d)

[alpmestan]

So, what do we want to do with respect to this issue? I think it would be OK to keep the current defaults as long as users can very easily override them, like with my Charset type above or any other way.

[cdupont]

Hi guys,
I have this issue. Should I use Bergmark's workaround above?

[expede]

Just to chime in since this the last comment was over a year ago: I also just ran into this 🙋🏼‍♀️

I’ll use the workaround above, and may extract it as a companion library. It would be nice to get the generalized version (e.g. #366) in the package directly.