Wiremock: Cannot use stubs for multipart requests with binary data with Spring Boot 2

Created on 5 Oct 2018 · 4Comments · Source: tomakehurst/wiremock

Observed result

The WireMock server responds with an 500 error instead of the stub mapping for a multi-part request with binary data after the upgrade from Spring Boot 1 to Spring Boot 2.

java.lang.IllegalStateException: No multipart config for servlet
    at org.eclipse.jetty.server.Request.getParts(Request.java:2331)
    at org.eclipse.jetty.server.Request.getParts(Request.java:2319)
    at com.github.tomakehurst.wiremock.servlet.WireMockHttpServletRequestAdapter.safelyGetRequestParts(WireMockHttpServletRequestAdapter.java:295)
    at com.github.tomakehurst.wiremock.servlet.WireMockHttpServletRequestAdapter.getParts(WireMockHttpServletRequestAdapter.java:279)
    at com.github.tomakehurst.wiremock.verification.LoggedRequest.createFrom(LoggedRequest.java:70)
    at com.github.tomakehurst.wiremock.stubbing.InMemoryStubMappings.serveFor(InMemoryStubMappings.java:76)
    at com.github.tomakehurst.wiremock.core.WireMockApp.serveStubFor(WireMockApp.java:164)
    at com.github.tomakehurst.wiremock.http.StubRequestHandler.handleRequest(StubRequestHandler.java:50)
    at com.github.tomakehurst.wiremock.http.AbstractRequestHandler.handle(AbstractRequestHandler.java:47)
    at com.github.tomakehurst.wiremock.servlet.WireMockHandlerDispatchingServlet.service(WireMockHandlerDispatchingServlet.java:108)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)

Steps to reproduce

I have created a repository which demonstrates the minimal version of this problem here:

https://github.com/jmewes/wiremock-issue-1007

Environment

WireMock version: 2.19.0 (which depends on Jetty 9.2.24.v20180105)
Spring Boot version: 2.0.5.RELEASE (which depends on Jetty 9.4.12.v20180830)

Related issues

Source

jmewes

👍4

Most helpful comment

Thanks for posting this. I'll try and find time to take a look this week. At face value your solution looks good, but I'd like to consider it a little more before committing to it.

tomakehurst on 15 Oct 2018

👍3

All 4 comments

With this patch the described scenario would work for us:

diff --git a/src/main/java/com/github/tomakehurst/wiremock/servlet/WireMockHttpServletRequestAdapter.java b/src/main/java/com/github/tomakehurst/wiremock/servlet/WireMockHttpServletRequestAdapter.java
index bd0e5f3..808c6c9 100644
--- a/src/main/java/com/github/tomakehurst/wiremock/servlet/WireMockHttpServletRequestAdapter.java
+++ b/src/main/java/com/github/tomakehurst/wiremock/servlet/WireMockHttpServletRequestAdapter.java
@@ -36,6 +36,7 @@ import java.io.IOException;
 import java.io.InputStream;
 import java.nio.charset.Charset;
 import java.util.*;
+import javax.servlet.MultipartConfigElement;
 import javax.servlet.ServletException;
 import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.Part;
@@ -275,6 +276,8 @@ public class WireMockHttpServletRequestAdapter implements Request {
                 String contentTypeHeaderValue = from(contentTypeHeader().values()).join(Joiner.on(" "));
                 InputStream inputStream = new ByteArrayInputStream(getBody());
                 MultiPartInputStreamParser inputStreamParser = new MultiPartInputStreamParser(inputStream, contentTypeHeaderValue, null, null);
+                MultipartConfigElement multipartConfigElement = new MultipartConfigElement((String)null);
+                request.setAttribute("org.eclipse.jetty.multipartConfig", multipartConfigElement);
                 request.setAttribute(org.eclipse.jetty.server.Request.__MULTIPART_INPUT_STREAM, inputStreamParser);
                 cachedMultiparts = from(safelyGetRequestParts()).transform(new Function<javax.servlet.http.Part, Part>() {
                     @Override

Is this an acceptable solution?

jmewes on 5 Oct 2018

Thanks for posting this. I'll try and find time to take a look this week. At face value your solution looks good, but I'd like to consider it a little more before committing to it.

tomakehurst on 15 Oct 2018

👍3

We've stumbled into the same problem updating our embedded jetty engine to 9.4.10 (.v20180503). Running internal tests using wiremock to stub external systems resulted in the same issue. Can confirm that the patch above will fix our problem.