On Thu, Aug 22, 2024 at 07:26:58AM -0500, Adam Porter wrote:

[...]

> From an API perspective, I'm not sure.  My idea for plz.el is to provide a
> simple, somewhat idiomatic Elisp API for making HTTP requests (and, of
> course, to make "correct" requests, in compliance with specifications and
> expectations).  Given the relatively few clients of plz thus far, some
> issues are yet to be fully explored and developed, and encoding/decoding may
> be one of those rougher edges.  For the use cases I'm aware of, it seems to
> work well and correctly, but there are undoubtedly improvements to be made.

Another point I haven't seen in this discussion is that HTTP also may
carry metadata about what it thinks the content encoding is. This may
involve the server configuration too.

You may choose to ignore it, but then you need to convince all the
moving parts to agree on that (i.e. an Apache on the other side might
happily tell your client that it is sending "text/plain; charset=UTF-8"
or something similarly funny (note: UTF-8 isn't a charset :-) depending
on the web server config, the content of some mimetype database and
so on.

You'll have to make sure curl and Emacs do the right thing with that
(which might be "nothing").

Cheers
-- 
t