XPA 3.3g HTTPCall Post - progress but no solution

Todd Baremore

I wrote a node script to capture what HTTPCall() is sending and found two issues.

This is the message I am sending

This is what HTTPCall() is sending
XPA 3.2e    "message":"<message>testing</message>"       correct
XPA 3.3g    "message=<message>testing</message>":""     incorrect


Peter Ashworth

Hi Todd

It's entirely possible that Magic has broken something and you might have to submit a support ticket to isolate/sort this.

Are you doing something like:  HttpCall('POST','http://url.com','message=<message>testing</message>','')  ?

Its kind of interesting to see the 3.2e convert into a JSON ish fashion. If my above assumption is correct I would have expected the 3.3g result albeit without the ":" at the end. Can you also try catching it in wireshark?

Obviously you are seeing a different output between the two versions with the same script catching them so thats not in question. Can you download different 3.3x versions and see if it breaks in a specific version? 3.3e release notes mention some stuff in this area.
141969 If 'Accept-Encoding: gzip, deflate' header is present in the URL, some garbage data was displayed in response to HTTPFramework=DotNet/Soap.
151005 The function HTTPCall() was not working with Digest and Basic Authentication when HTTPFramework=DotNet.

3.3d added support for PATCH verb.

So they have certainly been tinkering in this area and its possible they have upset something.

I can't really give personal experience with this anymore as we have since offloaded our HttpCall work to an in house dll due to a need for better TLS support as most of our stuff was https and Magic native TLS support wasnt cutting it.

I don't know if you try doing a http communication inside a .net snippit in xpa if that has full TLS access or not but if its not a concern then you could always try writing a central program with a .net snippet to handle your http calls from.

You could also maybe try the different HTTPFramework types (D is default I think, the other is J) to see if that makes a difference. Also whilst HttpPost is depricated it will still work if thats the verb you are trying to do so it might be worth giving that method a try to see if there is different behaviour.



Andreas Sedlmeier

Hi Todd,

On Wed, Feb 12, 2020 at 07:42 PM, Todd Baremore wrote:
I wrote a node script to capture what HTTPCall() is sending and found two issues
Better do what Peter suggests and look what is really going over the wire by using a proxy (like fiddler) or network monitor (like Wireshark).
A http proxy is much easier to use and the reason is, that you need to look into http headers as well.

So what is the exact Http call you do ? And what do you actually get on server side for http headers and body ?

Since ever the default Magic encoding used when you send something but do not specify content type is, I think,. application/x-www-form-urlencoded
And it looks a bit as if Magic used that because you forced it to by NOT specifying a content-type.

>> XPA 3.3g    "message=<message>testing</message>":""     incorrect
This is a broken name-value pair for a application/x-www-form-urlencoded message

>> XPA 3.2e    "message":"<message>testing</message>"       correct
This is broken/partial JSON because following would be valid JSON
' { "message": "<message>testing</message>" }' 

If its not JSON what they expact but name=value pairs with (possibly) quoted text in a form encoded message you need to url/formencode the text so correct would be 

Now Magic dois not have JSON handling anyway so if you set following header (not both)
If you post valid JSON: Content-Type: application/json
If you post something (including broken JSON): Content-Type: application/octet-stream
All would be OK I guess (all versions) because Magic would not touch the message and consider it to be "binary"

If recipient of your message is however a REST API and you do not set Content-Type: application/json
The service should reject it with http status 400 (:=bad request)

Obviously it doesent. because its a propietary API and the guys who implemented it, did not yet start to think about interopeability and API designs.
When they do, they will reject both of your messages since both are malformed.

Best regards,



This is the message I am sending

This is what HTTPCall() is sending
XPA 3.2e    "message":"<message>testing</message>"       correct
XPA 3.3g    "message=<message>testing</message>":""     incorrect

Andreas Sedlmeier

P.S.: If it is like I suspect and the issue it with the content-type and the message encoding/format then this is not a bug but a "change of behaviour".

Happened in the past that Magic fixed a bug or inconsistency and broke existing code. Not that often because MSE always considered a "change of behaviour" worse than a bug and they would (most of the time not fix the bug therefore but leave it as is, or come up with a Magic Special or so).

I do just fear that they do not have the ressources to do it like that anymore but fix bugs as they see them and then have insufficient testing in place in order to see whats the impact on old versions , .... . 

Im wondering anyway what the point of using Magic Http is ? THey may modernize the underlying libraries, the poor concept of Magic Http functions however remains as is and you are much better of when you /f.i.) use .NET. There's actually samples for that in Online demo because its simply close to undoable to implement more complex protocols (like Oauth2 or so) with Magic Http - which is the reason why MSE does not use Magic Http for this - but .NET instead ... themselve.