feat: add xml content type custom validation

[ceifa]

Closes httptoolkit/httptoolkit#94

Things to consider:

• Add a debounce to the validation: on my tests it went very fast and I don't think it is needed, but maybe for slow pcs it can benefit from a debounce so it doesn't get validated on every input key.
• Magic number used (10): I could have created a logic with the parser to know exactly when the marker ends, but I don't think the compute it's worth it versus the benefit

[CLAassistant]

All committers have signed the CLA.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	fast-xml-parser@​5.2.3

View full report

[pimterry]

Great work! Thanks for digging into that, this'll be really useful.

I've done a quick test, and it seems super fast even with quite large XML documents, so I'm not too worried about debouncing. Most very large documents will be in intercepted traffic anyway - where they're generally readonly.

The 10-character line isn't great though I think... I've opened an issue on fast-xml-parser (NaturalIntelligence/fast-xml-parser#753) to see if they're interested in adding end column info to validation results in future (I don't think any significant compute work should be required most of the time - in lots of cases it's known from an existing regex match etc - it just that it needs exposing) but we'll have to work without that for now.

I think the best option might be to just highlight from the start column to the end of the line. That's not perfect, but I think will work perfectly in most cases, since we automatically prettify XML when you view intercepted traffic (so there's usually one tag per line anyway). People entering their own XML on the Send page will probably use whitespace, so this will cover the right code automatically. In any scenarios where it is wrong, at least it will start in the right place so it's still easy to see where the problem comes from. That seems better than an arbitrary magic length to me, what do you think?

There are some small issues here with setting/unsetting the validation though. I've done some testing and:

• If you create an POST request on the Send page, select XML, and enter some slightly invalid XML then it shows errors as expected, but if you then change from XML to JSON it adds JSON errors but doesn't remove the XML errors. We need to reset the markers if the model language changes.
• When switching between requests in the View page, XML validation doesn't turn off if you change from an XML request to another type of request: if you go from a valid XML response (testserver.host/xml) to a valid JSON response (testserver.host/json) you then see XML validation errors on the JSON.

These are probably related. I forget exactly how the Monaco model lifecycle stuff works in depth, but we do need to make sure that this works nicely with state transitions like these.

[ceifa]

Thanks for opening the suggestion issue on the library, it didn't come to my mind.
I forgot to test the XML validation "on other languages", just pushed a fix for the problems you noticed, I think it is working great now 😄