hgweb: encode WSGI environment using the ISO-8859-1 codec
The WSGI specification (PEP 3333) specifies that on Python 3 all strings passed
by the server must be of type str with code points encodable using the ISO
8859-1 codec.
For some reason, I introduced a bug in
2632c1ed8f34 by applying the reverse
change. Maybe I got confused because PEP 3333 says that arbitrary operating
system environment variables may be contained in the WSGI environment and
therefore we need to handle the WSGI environment variables like we would handle
operating system environment variables.
The bug mentioned in the previous paragraph and fixed by this changeset
manifested e.g. in the path of the URL being encoded in the wrong way. Browsers
encode non-ASCII bytes with the percent-encoding. WSGI servers will decode the
percent-encoded bytes and pass them to the application as strings where each
byte is mapped to the corresponding code point with the same ordinal (i.e. it
is decoded using the ISO-8859-1 codec). Mercurial uses the bytes type for these
strings (which makes much more sense), so we need to encode it again using the
ISO-8859-1 codec. If we use another codec, it can result in nonsense.
Do not strip innocent children. See https://bitbucket.org/facebook/hg-experimental/issues/6/hg-absorb-merges-diverged-commits
$ cat >> $HGRCPATH << EOF
> [extensions]
> absorb=
> drawdag=$TESTDIR/drawdag.py
> EOF
$ hg init
$ hg debugdrawdag << EOF
> E
> |
> D F
> |/
> C
> |
> B
> |
> A
> EOF
$ hg up E -q
$ echo 1 >> B
$ echo 2 >> D
$ hg absorb -a
warning: orphaned descendants detected, not stripping 112478962961, 26805aba1e60
saved backup bundle to * (glob)
2 of 2 chunk(s) applied
$ hg log -G -T '{desc}'
@ E
|
o D
|
o C
|
o B
|
| o F
| |
| o C
| |
| o B
|/
o A