Fixing the content-type check for XML. #725
Conversation
… work for content-types with charset (e.g. "text/xml;charset=UTF-8").
|
Would love to see this merged. |
|
There is one check failed, due to the code conflict. |
| @@ -628,7 +628,7 @@ public void setEditable(boolean enabled) { | |||
|
|
|||
| @Override | |||
| public int getSupportScoreForContentType(String contentType ) { | |||
| return contentType.toLowerCase().endsWith("xml")? 2 : 0; | |||
| return contentType.toLowerCase().contains("xml")? 2 : 0; | |||
There was a problem hiding this comment.
Isn't that dangerous, since it will also include content types that are not necessarily supported?
For example: application/ vnd.openxmlformats-officedocument. wordprocessingml.document which is the MIME-Type of a MS Word .docx file.
There was a problem hiding this comment.
@wilk-polarny This is a score to indicate which tab to choose when the response comes. You can switch to XML tab manually anyway. So, this is not a security measure against an invalid content. The main purpose is to open xml tab when the xml has come in response. The current issue is that the hint is not working.
There was a problem hiding this comment.
I agree that the current proposal is sufficient, but if the hold-up is because of how open-ended it is, we could tighten it up by checking to see if it ends in "xml" or if it contains "/xml;". A regular expression such as the following would work: (?:(xml$)|(/xml;.+)) It is unclear to me--is the "WhiteSource Configuration Change" issue still outstanding?
There was a problem hiding this comment.
@dmccarty-incomm The issue is that the maintainers do not process the merge requests. Whitesource validation failure is a minor issue which can be resolved easilly as well.
There was a problem hiding this comment.
How about split by ";" and check it?
text/xml;charset=UTF-8
[0] text/xml -> endsWith xml -> stop checking
[1] charset=UTF-8
|
I'd also love to see this "fixed", since the current behavior in 5.7.0 is super annoying. Wouldn't it be even better if the scoring logic would only analyze the Also matching against known/supported media-types would be beneficial, since the string |
The conflict is actually caused by a malformed whitesource file. That's another issue to be resolved. |
Did your suggested soloution in #760 |
Zipped jar file.
Archiv s jarem.
|
let merge it and release a fix immediately. |
|
agree |
|
At this point I think the ideal path forward would be for somebody to maintain a community-supported fork where fixes don't rot in MRs for years at a time. |
|
totally agree with you. But then i didnt make the repo public since i fear the legal department from SmartBear. who knows what all is a „registered trademark“ if we find some motivated maintainers, we could discuss this further. |
|
@ChristophKronberger that's a fair concern. Five years ago I'd have been much more motivated, but thankfully I believe my days of using SOAP are coming to an end. |
Shouldn't the project license, albeit a weird choice (EUPL) allow for that? |
Yes but only for the source code. i think the graphics like the Logo and names and some other things are trademarks.
https://www.soapui.org/open-source/soapui-license/ I think it should be possible but we would defently have to change these protected things. |
Fixing the content-type check for XML. Checking with endsWith did not work for content-types with charset (e.g. "text/xml;charset=UTF-8").