Wiremock support for multipart/related #1047

[Iain Campbell]

Hello, 

 

I'm looking to the goodness of wiremock to mock a multipart/related RFC-2387 stream. I have noted the following wiremock existing feature request:

 https://github.com/tomakehurst/wiremock/issues/1047. 

An open PR exists to update Wiremock to "Recognize multipart/related and multipart/mixed" (https://github.com/tomakehurst/wiremock/pull/1415).

Whilst this PR will nobly permit parsing multipart mime (multipart/form or multipart/mixed) content, from some local testing I have conducted it seems this PR cannot readily parse multipart/related RFC-2387 compliant streams ? I get the following stack trace on attempts to test parsing of a multipart/related message:

..

        at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:763)

        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)

        ... 12 more

Caused by: org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly

        at org.apache.commons.fileupload.MultipartStream.readHeaders(MultipartStream.java:570)

        at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:1052)

        at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:1017)

Has any user encountered similar ? It would seem the current revision of `com.github.tomakehurst.wiremock.http.multipart.PartParser` supports parsing RFC-1876 compliant multipart-form data streams. However, I don't think it covers RFC-2387 compliant multipart/related streams? 

In the situation my observations about multipart/related are correct, perhaps I can offer some ideas/proposals ? Perhaps I could contribute on feature https://github.com/tomakehurst/wiremock/issues/1047 with some help from the good people here ? I would need guidance/feedback from wiremock author's and main contributor to offer a best solution ? 

At a high level my initial proposal would be:

1. Add support for parsing multipart/related streams (RFC-2387). Possibly leverage existing a parser which supports multipart/related stream parsing ? e.g. https://github.com/eclipse-ee4j/metro-mimepull  I have already tested and confirm this library can parse multipart/related messages.

  - Adding such library would add a new compile time dependency to wiremock. Other (more suitable) similar libraries may exist to parse multipart/related messages. Happy to use another if recommendations can be given ? I certainly would suggest to avoid writing mime parsers if an approved one can be vetted. Perhaps someone has alternative ideas ? 

2. Update `com.github.tomakehurst.wiremock.http.multipart.PartParser` class to support multipart/related parsing (without impacting legacy behaviour)

3. Add/update unit tests to support the feature update.

I'd be happy to trash out proposal, contribute to a workable solution and to help or independently deliver a PR supporting multipart/related  parsing - if that works ?

Please let me know what you think. 

Thanks

[David Spence]

Hi,

I've encountered the same issue which you. I actually posted about this on Stack Overflow a few months ago.

https://stackoverflow.com/questions/72937569/malformedstreamexception-when-sending-multipart-http-request-to-wiremock

Our application sends multipart requests to an external API (which we have used Wiremock to mock so we can test our API independently). However since updating to Wiremock 3.32, it fails completely when we send a multipart request. The error is:

Caused by: wiremock.org.apache.commons.fileupload.FileUploadException: Stream ended unexpectedly

...

...

Caused by: wiremock.org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly

...

...

(Full stack trace in the Stack Overflow question above)

I trimmed down the request to the most basic I could and it still fails. It seems to fail on any multipart/xxx type. Our request which was working with earlier versions of Wiremock is now failing when we send content type as multipart/related.

Is there any workaround you know of or did this gain any traction? People on our team are using M1 macs and in an unlucky coincidence, the earliest version of Wiremock which supports M1 macs is 3.32, which means we are stuck where my team can't run these tests, as this version seems to introduce this problem.

Thanks