Replaced 'utf8' in ET.tostring with 'utf-8', invalid XML (400) otherwise#538
Conversation
|
Hm, I thought In any case, thanks, The change looks good to me. I will test it first and if everything looks OK, merge it into trunk. |
|
I thought that as well. But apparently, when using produces the following output: Whereas this produces this: So it only seems to make a difference when |
|
This actually seems as it may be a bug in lxml. The documentation states this: And the code is this: I'm not familiar enough with lxml to see what goes wrong, but it should not write a XML declaration for I will open a bug report on the lxml tracker, just in case. Update: here is the report https://bugs.launchpad.net/lxml/+bug/1470809 |
|
@jeverling Thanks for the additional context / details. I'm a bit busy right now, but I will try to have a look asap (probably on Sunday). |
|
@jeverling Thanks, I've merged changes into trunk. On a related note - when I was originally working and testing the changes, it mostly worked, but occasionally got 400 status code back. I was digging into it, but I never could consistently reproduce the issue or find the root cause (I thought there was something weird going on, on the Azure side). I wonder if there there is something "weird" going on, on the Azure side - e.g. some servers accept XML with non-standard encoding declaration and others don't. Although, I think it would be unlikely they have different versions / libraries running on different servers... |
Closes apache#538 Signed-off-by: Tomaz Muraus <tomaz@tomaz.me>
The XML that is generated by the Azure driver contains
encoding='utf8', which doesn't work, the Azure API returns a 400 response. If this is changed toutf-8, it does work. Adjusting theencodingargument passed toET.tostringsolved the 400 responses I was getting when usingex_create_cloud_service.