python3-fastrpc and xmlrpc.client compatibility about fastrpc

[volca02]

Yep, it's a bug. I'll fix it in frpc8.

I'll look into the kwargs for loads, it seems possible to do.

[volca02]

useBinary in loads was implemented in 01f566c

[volca02]

The way loads handles data is dependent on fastRPC library itself, which is trying to be smart, deciding whether it should use Binary or XML based unmarshaller by looking at the stream length and first 2 bytes.

You can craft arbitary length sequences that will pass as valid data, for example <sdfadsfasdfa

I don't currently see a way to enforce Binary unmarshaller to force the validation, I'll see what I can do here.

[volca02]

I found the reason the faultCode is sometimes unset - there is no guarantee the faultCode will be the first element in the xml stream:

<?xml version='1.0'?>\n<methodResponse>\n<fault>\n<value><struct>\n<member>\n<name>faultCode</name>\n<value><int>504</int></value>\n</member>\n<member>\n<name>fau ltString</name>\n<value><string>Err</string>...

or

<?xml version='1.0'?>\n<methodResponse>\n<fault>\n<value><struct>\n<member>\n<name>faultString</name>\n<value><string>Err</string></value>\n</member>\n<member>\n< name>faultCode</name>\n<value><int>504</int>...

The code that parses the fault is not able to handle the faultCode if it comes as a second value.

[sejvlond]

faultCode

ok, but it's a bug, right? and should be fixed in major 8 version?

fastRPC library itself, which is trying to be smart

would be nice to have some parameter in fastrpc.loads where I can specify content-type, for example:
fastrpc.loads(data, use_binary=True/False/None) where None should be default and it means, try to load it at your discretion (backward compatible) and True and False means use fastrpc or use xmlrpc. Because I know, what data I've got from content-type header.

[volca02]

We decided not to change the behavior of loads (tuple/non-tuple parameters) as it would likely break existing usage and would be hard to fix. We may implement an opt-in change later on, but we don't like the idea of postponing the frpc8 release to implement this.

The useBinary for loads will probably make it into the release.

[sejvlond]

We decided not to change the behavior of loads (tuple/non-tuple parameters)

and the behavior is: When method is not set, returns non-tuple, when method is set, returns tuple?

[volca02]

Yes. There is unknown amount of code that relies on the current behavior.

[sejvlond]

ok, I will wrap this for myself as well