doc/customizing.txt has a section "8-bit character set support in Web
interface" describing how a character set other than UTF-8 can be used
for sending web pages to the client, given an @charset form variable
which may result in a roundup_charset cookie being set.

The stated reason is "Unfortunately, some older browsers do not work
properly with utf-8-encoded pages (e.g. Netscape Navigator 4 displays
wrong characters in form fields).".  That text was added in 2004 - that
is, those browsers were "older" even then.  I think it would be
reasonable, in 2018, to say that those browsers are now completely
irrelevant and web pages sent to the client should always be sent in
UTF-8, so simplifying the code.

(I noticed this when fixing how actions returning binary data were
handled with Python 3; the re-encoding would break such actions for
Python 2, if anyone ever tried to use them together with the @charset
feature, which probably no-one ever did.)

Hi Joseph:

In message <1535915481.24.0.56676864532.issue2550998@psf.upfronthosting.co.za>,
Joseph Myers writes:
>New submission from Joseph Myers:
>
>doc/customizing.txt has a section "8-bit character set support in Web
>interface" describing how a character set other than UTF-8 can be used
>for sending web pages to the client, given an @charset form variable
>which may result in a roundup_charset cookie being set.

Does this mean that the code that supports roundup_charset would be
removed?

If so, is it possible that that could have another use?

If not, then I say remove it and the customizing.txt reference. There
will need to be a section in upgrading.txt that addresses how to
remove the customizing code in the tracker if it's in use.

On Sun, 2 Sep 2018, John Rouillard wrote:

> Does this mean that the code that supports roundup_charset would be
> removed?

Yes.  And all the code deal with conversions if self.charset != 
self.STORAGE_CHARSET, in both client.py and actions.py.

> If so, is it possible that that could have another use?

I don't see a use for it.

As far as I can tell, unless the form specifies @charset, a 
roundup_charset cookie will never be set in the first place.  And unless 
either the form specifies @charset or there is a roundup_charset cookie, 
the client's charset attribute is set to self.STORAGE_CHARSET (i.e. 
'utf-8') in __init__ and never changed afterwards, so all the code dealing 
with recoding to/from another charset is dead in that case.  And since 
Roundup always generates forms in UTF-8 unless @charset or roundup_charset 
are used, and does not use the accept-charset attribute on forms, form 
responses will always be submitted in UTF-8 so no recoding on input is 
needed.

In message <alpine.DEB.2.21.1809022133560.1285@digraph.polyomino.org.uk>,
Joseph Myers writes:
>On Sun, 2 Sep 2018, John Rouillard wrote:
>> If so, is it possible that that could have another use?
>
>I don't see a use for it.
>
>As far as I can tell, unless the form specifies @charset, a 
>roundup_charset cookie will never be set in the first place.  And unless 
>either the form specifies @charset or there is a roundup_charset cookie, 
>the client's charset attribute is set to self.STORAGE_CHARSET (i.e. 
>'utf-8') in __init__ and never changed afterwards, so all the code dealing 
>with recoding to/from another charset is dead in that case.  And since 
>Roundup always generates forms in UTF-8 unless @charset or roundup_charset 
>are used, and does not use the accept-charset attribute on forms, form 
>responses will always be submitted in UTF-8 so no recoding on input is 
>needed.

Works for me. Nuke it.

Joseph, did you remove the 8-bit support?

-- rouilj

I have not done anything on removing this support.