Forum Discussion
richie
6 years agoCommunity Hero
Hi ,
Just as an aside are you should you have the ContentType correct 'text/plain' as opposed to 'application/xml'? The reason i ask is that readyapi! won't treat your xml payload as xml.....it'll treat it as though its just a string of characters, NOT xml.
Obviously if your listening endpoint expects your xml as 'text/plain' then thsts something else as this defeats the object of sending it xml. Also it means that when your request hits your endpoint it means your endpoints parser wont do the eellformed xml check and wont be validatd against a schema unless the developers add extra code (that isnt required if the ContentType is correct) to handle this. I'd speak to the developers about this cos this is almost surely a defect.
Anyway....back to the original point ....control char sequences.
If you look at the top of your xml youll probably have an xml declaration that indicates xml version, character set, etc. By default xml uses utf-8, those 3 character sequences you mention (SOH/STX), arent being recognised by readyapi!'s xml parser, hence the reason im guessing those control char sequences are being replaced with ? chars.
Im curious how youre representing those char sequences cos sticking SOH anywhere would make the xml malformed....i cant visualise how youre representing this in your xml....wpuld you publish the xml just to understand better please?
Typically i would say you need to replace the problem character with its utf-8 supported escape sequence (e.g. represents a space in xml), and you say your webservice accepts the control char sequences, however i know that control characters were banned in xml v1.0, so i'm surprised your endpoint should accept your requests if they contain the control chars, so maybe another reason to talk to your developers? Obviously xml v1.1s been around for quite a while.....first thing first, id raise these points with the author of your requirement to query if these control chars should in fact be included in your request payloads cos at first guess im thinking they shouldnt.
Sorry about the ramble....i was typing out on my phone so cant see what ive written,
Cheers,
Rich
Just as an aside are you should you have the ContentType correct 'text/plain' as opposed to 'application/xml'? The reason i ask is that readyapi! won't treat your xml payload as xml.....it'll treat it as though its just a string of characters, NOT xml.
Obviously if your listening endpoint expects your xml as 'text/plain' then thsts something else as this defeats the object of sending it xml. Also it means that when your request hits your endpoint it means your endpoints parser wont do the eellformed xml check and wont be validatd against a schema unless the developers add extra code (that isnt required if the ContentType is correct) to handle this. I'd speak to the developers about this cos this is almost surely a defect.
Anyway....back to the original point ....control char sequences.
If you look at the top of your xml youll probably have an xml declaration that indicates xml version, character set, etc. By default xml uses utf-8, those 3 character sequences you mention (SOH/STX), arent being recognised by readyapi!'s xml parser, hence the reason im guessing those control char sequences are being replaced with ? chars.
Im curious how youre representing those char sequences cos sticking SOH anywhere would make the xml malformed....i cant visualise how youre representing this in your xml....wpuld you publish the xml just to understand better please?
Typically i would say you need to replace the problem character with its utf-8 supported escape sequence (e.g. represents a space in xml), and you say your webservice accepts the control char sequences, however i know that control characters were banned in xml v1.0, so i'm surprised your endpoint should accept your requests if they contain the control chars, so maybe another reason to talk to your developers? Obviously xml v1.1s been around for quite a while.....first thing first, id raise these points with the author of your requirement to query if these control chars should in fact be included in your request payloads cos at first guess im thinking they shouldnt.
Sorry about the ramble....i was typing out on my phone so cant see what ive written,
Cheers,
Rich
Related Content
- 5 years ago
Recent Discussions
- 5 days ago
- 10 days ago