Subject: bug#69381: mumi does not correctly display (some?) non-ascii characters

From: Christopher Baines <[email-masked]>
Date: Sat, 08 Feb 2025 09:40:40 +0000

Noé Lopez <[email-masked]> writes:

> Maxim Cournoyer <[email-masked]> writes:
>
>> Hi Noé,
>>
>> Noé Lopez <[email-masked]> writes:
>>
>>> Small update,
>>>
>>> I’ve investigated the issue in fibers and I now blame the guile web
>>> library for the issue.  Apparently it sets the port to ISO-8859-1
>>> encoding each time you call read-request, but it acts like « yeah don’t
>>> worry just use utf-8 for your body » in the docs.
>>>
>>> That’s fine UNLESS you use chunked transfers (omitting content-length in
>>> fibers), in which case it just decides to blow up :///// (it assumes one
>>> character = one byte)
>>>
>>> In the end I’m pretty sure any of this could have been avoided by just
>>> not replacing every character with question marks.  Had it kept the
>>> invalid bytes intact they would have translated back with no issue.
>>
>> Nice investigation!  Did you create an issue at [email-masked]?  
>> don't see it on the tracker.  Or perhaps this could be tackled from the
>> angle of fibers?  For example by adding a new failing test reproducing
>> the problem to its test suite, and going from there.
>>
>
> I talked about this with Christopher Baines at FOSDEM and he seemed to
> know much more about it than me, so maybe he can suggest a way forward?
>
> Starting with a failing test seems like a good idea.

I've raised a Pull Request which I think should help in fibers:

  https://github.com/wingo/fibers/pull/116

I think this issue should be possible to work around in Mumi as well,
the encoding on the port needs to be set, and I think Guile 3.0.10 needs
to be used.