HTTP /win API doesn't return valid XML

[Aircoookie]

When calling http://[esp-ip]/win, instead of the API response XML structure, sometimes an invalid response is displayed, similar to:
60255159000011011200751280-1010WLED Light

However, it is seems like the correct response is sent and there is some sort of interference with the Chrome rendering engine. Not reproducable with Firefox. Further investigation is needed.

Possibly also affects MQTT /api endpoint.

[timothybrown]

I get the same response in Safari. (iOS and macOS)

[brentbrooks70]

Very odd, if I look at the incoming data from the device it appears to have NO XML tags

but when passed to my rule engine they are there....

of course it is currently looking for JSON and not XML as I had written this to parse the JSON from the http://IP/JSON originally but I can work with that.

If there is anything I can do to help test or whatever please let me know.
@Aircoookie, amazing project, so glad I found this and hope I can help contribute in some manner

[Aircoookie]

Thanks for your help :)
Ok, I investigated a bit further and this is indeed a very strange issue.
First of all, highly browser or tool based. I've inspected the raw data coming from the ESP using wireshark as well as some custom javascript, all working fine. As to be expected, there is no issue in the WLED app either (which uses the HTTP api). Now for my browser testing. I could not reproduce the issue a single time in Firefox, Edge, or Chrome for Android.
Interestingly, in Chrome desktop i get the following error in the javascript console when the issue happens:

chext_driver.js:44 Uncaught TypeError: Cannot set property 'cssText' of undefined
    at chext_driver.js:44
    at Tj (chext_driver.js:30)
    at Hl (chext_driver.js:44)
    at Nl (chext_driver.js:46)
    at Dl.x.R (chext_driver.js:244)
    at at (chext_driver.js:145)
    at new Lx (chext_driver.js:205)
    at new Px (chext_driver.js:206)
    at new Rx (chext_driver.js:206)
    at chext_driver.js:236

A quick web search doesn't seem to provide any similar cases, but the XML tags getting stripped seems to be a client side issue. Let me know if you have more findings! Maybe it can be solved by some response headers. I'll also try adding encoding info to the xml, maybe that is an issue. I don't remember having this issue in Chrome a few months back, so either a Chrome or WLED update must have caused it. Though it's odd that the issue is appearing in HA (or the software you are using) as well...

[stale]

Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs.
Thank you for using WLED!