XML RPC changes between 3.7 and 3.9 yield 401 http error

Chris Angelico rosuav at gmail.com
Sat Mar 27 17:49:21 EDT 2021


On Sun, Mar 28, 2021 at 5:00 AM lucas <lucas at bourneuf.net> wrote:
> I finally took time (thanks to Florian R.) to get a reproducible example
> of my problem, as asked previously by ChrisA.

Thanks! With this in hand, I can play around with it.

> On debian, Python 3.7, i got:
>
>      127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
> HTTP/1.1" 404 -
>
> On Arch, python 3.9, i got:
>
>       aluriak at arch❯ python3.9 p.py server
>      127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -

On Debian, with both versions having been built from source, the same
occurs. Furthermore, Python 3.8 behaves as 3.7 does. This definitely
changed in 3.9.

> Note that the two outputs differs in two ways:
>
>      127.0.0.1 - - [27/Mar/2021 18:31:13] "POST /?u=user&p=password
> HTTP/1.1" 404 -
>      127.0.0.1 - - [27/Mar/2021 18:35:45] "POST /RPC2 HTTP/1.1" 200 -
>
> The first contains the arguments, and the second contains the path.
> Sounds like there is something wrong with both modules.

One point of note is that the request as given actually doesn't have a
slash. I think that's technically wrong, but a lot of systems will
just implicitly add the slash. That, coupled with commit 9c4c45, is
why you're seeing "/RPC2" in there. That distinction vanishes if you
change your client thusly:

url = 'http://' + URL + '/?' + urlencode({'u': USER, 'p': PASSWD})

Actually, it looks like all the changes came in with that commit. The
old way used some internal functions from urllib.parse, and the new
way uses the public function urllib.parse.urlparse(), and there are
some subtle differences. For one thing, the old way would implicitly
readd the missing slash, thus hiding the above issue; the new way
leaves the path empty (thus triggering the "/RPC2" replacement). But
perhaps more significantly, the old way left query parameters in the
"path" portion, where the new way has a separate "query" portion that
is being lost. Here's the relevant BPO:

https://bugs.python.org/issue38038

It seems to have been intended as a pure refactor, so I'd call this a
regression. Fortunately, it's not difficult to fix; but I'm not sure
if there are any other subtle changes.

The regression's already been reported so I'm adding to this issue:

https://bugs.python.org/issue43433

Hopefully that solves the problem!

ChrisA


More information about the Python-list mailing list