Malformed return not displayed and not viewable in any manner

[designgears]

Is your feature request related to a problem? Please describe. When debugging an api endpoint that returns malformed json/xml/etc... the request is successful but the response tab will be empty with no way to see the raw return to see that the return was malformed.

Describe the solution you'd like Add a tab next to Response or an options in the menu to see the raw output called Raw or Original, something similar to how you can see the original email with all of the headers in such in gmail.

Describe alternatives you've considered Option to dump the raw return to the extensions console output.

[rangav]

Thanks for the feedback @designgears, will add to roadmap.

Can you please a sample malformed response for testing

[designgears]

@rangav while I can't provide my exact example, in my testing a broken compression function was only allowing 1024 characters causing it to cut off about half of the returned xml. I think an easy example would be anything with a missing closing tag or a cut off tag. Also returning a line break before the xml tag would break it.

[rangav]

@designgears I was able to output the malformed xml

you can test using this url https://www.thunderclient.com/t/echo

[rangav]

works for json also for missing closing bracket

[designgears]

@rangav what about a chopped off tag?

<?xml version="1.0" encoding="UTF-8"?>
<text>
  <name>Test</name>
  <area>boston</ar

Or a line break before the xml

<?xml version="1.0" encoding="UTF-8"?>
<text>
  <name>Test</name>
  <area>boston</area>
</text>

I think the xml tag is needed for it to trigger the error with the line break.

[designgears]

Looks like your echo endpoint is trimming off the linebreak before returning it.

Edit: I'm going to remove the fix in my code and replicate what was happening before, must have been something truly mangled that was getting returned.

Edit2: After a little poking around I can see on my end the line break at the start is causing the gzip/deflate in the php nusoap library to do some odd stuff. Initial thoughts are, the compressed size is being used but the original uncompressed xml is being sent back.

Edit3: after some more testing the gzip/deflate function is returning the correct string and size, but it uses a print $var; after that to dump the return into the page. That drops the gzip/deflated string right after a line break created by a config file that has multiple line breaks after the closing php tag.

In the end the problem is a content length that is too short because of an unaccounted-for line break added to the return after the gzip/deflate function causing the end of the xml to get cut off and the line break causing the xml parser to throw an error because the xml tag can only be in the first line.

Not sure you'd be able to account for that issue easily, in the end using the generated curl command let me see the output and set me on course to finding the problem.

It would still be a nice to have feature!

[rangav]

Can you let me know how to re-produce the issue, because I can see the output for malformed xml/json.

[rangav]

Closing this issue, feel free to re-open if needed