When a request is interrupted to do authentication it is wrapped and
then later restored in=20
It seems to be restored with the UTF-8 chars garbled. (My opinion of the
source of the problem)
Richard Jones=92 description of the garbling:
=93=85the garbled characters arise when going from an 8 bit encoding to =
bit encoding. This explains why the original single character is
re-interpreted as two separate characters, the first one always being =
(an A with a tilda above it), which is represented by ASCII 195. =94
Anyone got any takes on this? It must hit everyone with intl chars: in
fact it even garbles apostrophe.
---> post of eg submission data
---> login state is checked: expired
---> post saved (perhaps garbling) login forced=20
---> login successful, orignal post restored (garbling could also occur
here) and sent on=20
---> result *?%&%$=A7 !
You wont notice this till you come back to the data of the submission
step which had its entry garbled, so you may not immediately connect it
with the forced authentication step.
It seems to happen on all browsers (or at least IE, Firefox and Safari)
4 Bld. de la Libert=E9
+33 499 91 0655
+49 172 834 2620