Content-Type Header for Multipart-Requests should be checked case-insensitive

[mufasa1976]

References

When testing SOAP-Requests with MTOM enabled the Standard SAAJ Implementation sends a HTTP-Header Content-Type: Multipart/Related; boundary=.... This leads to a Failure on Wiremock Multipart Behaviour because it only has checked against lowercased multipart/.

Instead it checks against a case-insensitive Regular-Expression ^multipart/.*.

Can this be also merged to the Java-8 related Versions?

Submitter checklist

• Recommended: Join WireMock Slack to get any help in #help-contributing or a project-specific channel like #wiremock-java
• The PR request is well described and justified, including the body and the references
• The PR title represents the desired changelog entry
• The repository's code style is followed (see the contributing guide)
• Test coverage that demonstrates that the change works as expected
• For new features, there's necessary documentation in this pull request or in a subsequent PR to wiremock.org

[dieppa]

Hello @mufasa1976 , can you fix the pipeline, so we can review it.

Thanks!

[mufasa1976]

I've tried to fix the formatting Issues on MultipartBodyMatchingAcceptanceTest without knowing what to fix.
Unfortunatly this try also fails and I don't know where to look for the formatting Rules which the Code violates.

On my local Machine (Ubuntu 22.04.4 LTS) the Task ./gradlew :check --stacktrace --no-daemon leads no no violations.
Can you please help me just saying, which rules the Test-Code violates? And maybe why the Gradle-Task would not fail on my local Machine?

Thank you very much

[dieppa]

Can you give it a try running ./gradlew :spotlessApply ?

[mufasa1976]

I've tried but there were no File changes after ./gradlew :spotlessApply

[dieppa]

Generally speaking this is right and improve the current behaviour(not only for case insensitive aspect), but I would like to support also potential white spaces at the beginning. I suggest to trim the String or add it in the regular expression.

[mufasa1976]

I agree. I've updated the regular Expression to ignore any whitespace character at the beginning of content-type

[dieppa]

Nice, one. Can you keep both, with and without spaces?😃

[mufasa1976]

This regular Expression already handles both cases

[mufasa1976]

Or did you mean the Test Case?

[dieppa]

yeah, I meant the test case,hehe

[mufasa1976]

Ok, i've adapted the Test so that the same Content will be sent twice. One time with leading spaces before the content-type and one time without leading spaces

[dieppa]

Nice work! Just one last change and it's done; keep two independent methods, one without spaces(acceptsAMultipartRequestWithCamelcasedContentTypeInformation) and another one with them(acceptsAMultipartRequestWithCamelcasedContentTypeInformationWithLeadingSpaces).

It sounds stupid, but that makes clear and easier to spot what has gone wrong in the future.

[dieppa]

Regarding the formatting, this should work:

1. run ./gradlew spotlessJavaCheck -> This should fail
2. run ./gradlew :spotlessApply -> This should fix it

However, if this doesn't work, let me know.

[mufasa1976]

Nice work! Just one last change and it's done; keep two independent methods, one without spaces(acceptsAMultipartRequestWithCamelcasedContentTypeInformation) and another one with them(acceptsAMultipartRequestWithCamelcasedContentTypeInformationWithLeadingSpaces).

It sounds stupid, but that makes clear and easier to spot what has gone wrong in the future.

Ok, I have splitted one test into 2 tests with the appropriate Method-Names

[mufasa1976]

Regarding the formatting, this should work:

1. run ./gradlew spotlessJavaCheck -> This should fail
2. run ./gradlew :spotlessApply -> This should fix it

However, if this doesn't work, let me know.

Thank you very much. Indead this had helped!

[dieppa]

Merged it!

And sorry for the formatting, I believe the fix is just run those comments I mentioned, but we want to ensure and will document it.

Thanks for your contribution