Hi - I am using version 1.42, and am using JUnit 4 and the SpringJUnit4ClassRunner.

I have a JUnit test case in which I have created a number of test cases that establish GET mappings, all of which work when the test class is run. However, when I add a PUT mapping (the URL is very similar but not identical to the GETs) it often fails with a read connect timeout. Although other times it succeeds quite rapidly. What I've found is that if I do a Thread.sleep(5000) at the beginning of the test method, it works consistently.

Could the start-up of the server not be fully complete when the test method begins? Maybe the SpringJUnit4ClassRunner is not waiting for the rule to be fully initialized.

Have you ever encountered an issue like this?

In JUnit 5, @Rule and @ClassRule is superseded by @ExtendWith, which requires extension class. And it seems like extension for WireMock is not yet supported. Is there any alternative way to use WireMock with stubbing and verification via JUnit 5?

Wiremock is using a version of Jetty 9.2.x and for the new version of Spring Boot with the WebFlux (2.0.0.RELEASE) Reactive threads sometimes the calling thread stops and hanging when calling Wiremock. This problem occurs only in version 9.2.x and not in 9.4.8.v20171121 of Jetty.

I understand that you want the JDK 7 support, but in that case you'll lose support for newer technologies/frameworks like Spring WebFlux, HTTP2 and so on... Wiremock with version 9.2.x of Jetty is unusable with reactive threads because it randomly stops hanging.

I saw your conversation on https://github.com/tomakehurst/wiremock/pull/887 thread and the commit https://github.com/tomakehurst/wiremock/commit/4368d316ec239bac305f1faadedab24765bbe4b6, but somehow it will be very nice if you can provide support for the new Spring 5 WebFlux (Spring Boot WebFlux 2.0.0.RELEASE).

Add another JAR artifact to the build that's Java 8+ only and uses the latest Jetty version. This would probably involve splitting the source tree up into core and version-specific parts, which the build would include/exclude for the various output JARs.

Add some runtime detection of the environment i.e. are we on Java 8+ and Jetty 9.4+, and load the HTTP/2 code only under these conditions, such that NoClassDefFoundErrors and the like aren't thrown when running on Java 7.

Any of the above solution should be fine. The idea is to upgrade also the Wiremock Standalone which is used by spring-cloud-contract-wiremock.

Please see related issues: https://github.com/spring-projects/spring-boot/issues/10569 https://github.com/reactor/reactor-netty/issues/264 https://github.com/spring-cloud/spring-cloud-contract/issues/606

This doesn't seem to be a problem on my own computer. However when I run the maven build on Jenkins, it always fails with the following message: Caused by: java.net.SocketException: SocketException invoking http://localhost:8098/some/useless/path: Unexpected end of file from server.

I searched Wiremock's config, it doesn't seem that I can change the server timeout settings.

Feature request

As discussed with Tom via the mailing list...

We're looking to be able to request match on a dynamic date. We have a few calls which always have a date a number of days in the future from the present date. So ideally we want to be able to use the date helper in the request matching.

e.g.

  "priority": 5,
  "request": {
    "method": "POST",
    "url": "/api/service/fetchPolicy",
    "bodyPatterns": [
      {
        "matchesXPath": "//*[local-name() = 'PolicyNumber' and @Val = 'pol123456']"
      },
      {
        "matchesXPath": "//*[local-name() = 'StartDate' and @Val = '{{now offset=\'30 days\' format=\'yyyy-MM-dd\'}}']"
      }
    ]
  }

Being able to use the full range of options within the date and time response templating helper to set the time/date in different formats, offset by days, hours, minutes etc would be ideal.

As promised, here's a PR that integrates my wiremock-snapshot extension. It adds a new API endpoint, /__admin/snapshot, for recording stub mappings from the request journal. The README has more details, but here's a summary of the options it accepts:

• "filters" - Request patterns to use for determining the requests for which to create stub mappings.
  • Possible values: Identical to /__admin/requests/find
  • Default: no filtering.
• "persist" - If set to true, persist stub mappings to disk. Otherwise, just output them.
  • Possible values: true, false
  • Default: true
• "sortFields" - Array of fields in the request to use for sorting stub mappings, mainly for output.
  • Possible values: "url", "method", or a header name (e.g. "Accept")
  • Default: no sorting.
• "captureHeaders" - Header matchers for including headers in the stub mapping. The request is matched against each matcher, and the associated header is added to the stub mapping if there's a match.
  • Possible values: Request matchers for headers.
  • Default: none
• "outputFormat" - Determines response body.
  • Possible values: "ids" to return array of stub mapping IDs, "full" to return array of stub mapping objects
  • Default: "ids"

Design issues

Filtering

Filtering is currently request-only. I'm not sure if response filtering is desired. If so, we'd probably want to add a new ResponsePattern class (analogous to ResponsePattern) to encapsulate matchers for the response. This would be best accompanied with some refactoring to make Response into a an interface implemented by LoggedResponse .

Body file extraction/naming

Currently, the API does not extract the response bodies to a separate file. While it'd be easy to add a flag to enable this, I think more granularity is needed. Body file extraction is useful for large binary responses, but generally undesirable for small JSON responses. Perhaps we can add a "bodyFileCritera" option consisting of matchers that determine whether or not to extract the body. That way, you could use "headers": { "Content-Type": { "doesNotMatch": ".*json.*" } } } to only extract non-JSON responses. Again, we'll probably want to add a ResponsePattern class for this, and a "bodySize" matcher to allow matching by the size of the body.

Uniqueness/Deduplication

To ensure stub mappings are unique, I have StubMappingTransformer#apply() generate a MD5 hash of the RequestPattern JSON and set that as the UUID. This is pretty hacky, but it seems to work well. I considered just using hashCode(), but that's not appropriate since it has a high collision probability and the result is not guaranteed to be consistent between executions (see the JavaDoc).

This makes me wonder why StubMapping IDs are random instead of being a content-based hash. I see this was added in PR #306, but it doesn't seem uniqueness was considered.

Outputting

The options available in "outputFormat" seem sufficient to me. If we add body file extraction, we may want to add another output format to serve everything in a zip file.

Sorting

I implemented the ability to sort the stub mappings by the request URL, method, or a header. The main use case for this is to make it easier to manually edit the stub mappings. This is arguably better served by extension points, so it might be better to just remove this feature.

The class used for sorting, RequestFieldsComparator, is pretty hacky and a violation of the open-closed principle, but I couldn't think of a better implementation.

Extension points

An extension point for modifying StubMapping objects would be easy to add. Specifically, we could have WireMockApp#buildAdminRequestHandler() pass in the stub mapping extensions along with the API extensions to AdminRoutes, which could then call

router.add(POST, "/snapshot", new SnapshotTask(this.stubMappingTransformerExtensions));

instead of

router.add(POST, "/snapshot", SnapshotTask.class);

Adding the ability to customize the file names for persisted mappings would be more complex. Perhaps we could use a wrapper class, e.g. RecordedStubMapping, that would allow extensions to set the name for the mapping file and (if applicable) the body file.

Statefulness/Scenarios

It'd be easy to detect duplicate requests and then set the StubMapping scenario name, but I'm not quite sure about naming. We could just use something like UniqueFilenameGenerator to auto-generate the scenario name, but we'll probably want to have some way of customizing it. Maybe a "scenarioNameTemplate" option that accepts a Handlebars template?

edit: Minor clarifications

I've previously forked (privately inside a company) to add support for things like proprietary auth mechanisms. I'd rather just take master version + add things to the class path.

I was thinking of adding an interface something like:

package com.github.tomakehurst.wiremock.http;

public interface RequestResponseExtension {
    ResponseDefinition filter(Request request, ResponseDefinition responseDefinition);
}

Then loading all implementations off the class path using https://github.com/ronmamo/reflections (or perhaps java service loader api but this is more work for people providing extensions)

These could then be picked up in the StubRequestHandler and each request/response passed through?

I wasn't planning on adding a way to prime them and just have them all picked up and used by default?

What do you think?

First, i apologize if this is not the right place for a request.

Secondly, I know that from a previous threads this is not allowed per design: https://github.com/tomakehurst/wiremock/issues/62 and https://github.com/tomakehurst/wiremock/issues/139

Ah, no that's correct - you can't forward proxy onto SSL. This is a general limitation, as the whole point in SSL is preventing man-in-the-middle attacks.

Is there a way to add this? maybe something like --enable-browser-proxying-with-ssl?

It would be great to proxy everything from our IIS to it and have to forward all requests to the original endpoint, unless we post an overide for a specific url which WireMock could mock. Our endpoints are about 50% SSL and about 50% non SSL.

Yes, it's true. On OSX, I encountered an obscure bug.

To uncover it, I added print statements that I implemented by decorating breakpoints in IDEA:

This is all in apache's httpcore version 4.4.1. In org.apache.http.protocol.HttpRequestExecutor, I added non-suspending and logging breakpoints as follows:

Line 122: "REQ: " + System.identityHashCode(conn) + ": " + conn + " => " + request Line 126: "OK: " + System.identityHashCode(conn) + ": " + conn + " => " + request Line 128: "FAIL: " + System.identityHashCode(conn) + ": " + conn + " => " + request + ": " + ex

A typical output, which shows the bug at the end:

REQ: 120493608: CPoolProxy{148.121.152.75:56553<->10.179.121.244:8084} => [URL] REQ: 1402900645: CPoolProxy{148.121.152.75:56552<->10.179.121.244:8084} => [URL] OK: 120493608: CPoolProxy{148.121.152.75:56553<->10.179.121.244:8084} => [URL] OK: 1402900645: CPoolProxy{148.121.152.75:56552<->10.179.121.244:8084} => [URL] REQ: 1848886687: CPoolProxy{148.121.152.75:56552<->10.179.121.244:8084} => [URL] FAIL: 1848886687: CPoolProxy{0:0:0:0:0:0:9479:984b:56552<->10.179.121.244:8084} => [URL]: org.apache.http.NoHttpResponseException: The target server failed to respond

(The [URL]'s are request objects I have edited out, for clarity.)

The System.identityHashCodes ensure I am printing the same object. We see object #1848886687 goes from one state at request time, and to a new state after. The new state is that the local address has mysteriously become 0:0:0:0:0:0:9479:984b!

What is that, you say? It is an IPv6 address format. However, it describes the same IPv4 IP address! You can work out what 94.79.98.4b is in decimal for yourself ...

When does this change occur? When the socket connection flushes the outgoing data. (I.e. the request.) This happens in org.apache.http.impl.io.SessionOutputBufferImpl, line 126:

   this.outstream.write(b, off, len);

Don't ask me how it happens, but before we call write here, the connection is fine. And SOMETIMES, when the call returns, it is screwed, and unable to receive incoming data. (Manifesting as NoHttpResponseException: The target server failed to respond, as above, and the FAIL breakpoint hitting.) Not every time, but pretty often. This is why I suspect multi-threading issues.

I am serious. Do NOT ask me how this happens. Could be an issue with http-core and/or my network setup. I just know the pull request makes the FAILs go away.

PS: Sorry about the whitespace/formatting diff, that's my opinionated IDEA. The change is only creating a new client every time. I can clean that up, but it'll have to be a little later.

PPS: This is NOT an april fool's!

Jetty 11 support, closes https://github.com/wiremock/wiremock/issues/1760

• [x] Finish upload refactoring
  • [x] multipart/mixed is not handled yet (4 tests in the MultipartBodyMatchingAcceptanceTest)
• [X] Fix logging support (slf4j 2.0.0): switched to Logback 1.4.0 since Log4j2 does not support Slf4j 2.0 APIs (yet)
• [x] HttpServletResponse::setStatus(int sc, String sm) is deprecated and not implemented by Jetty 11 (StubbingAcceptanceTest::settingStatusMessage)
• [x] Fix failing test cases: 1 test case is failling
  • [x] GeneralCodingRulesTest > RULE_NO_CLASSES_SHOULD_THROW_GENERIC_EXCEPTIONS FAILED

Wiremock registers GzipFilter with default configuration:

com.github.tomakehurst.wiremock.jetty9.JettyHttpServer

mockServiceContext.addFilter(GzipFilter.class, "/*", EnumSet.of(DispatcherType.REQUEST, DispatcherType.FORWARD));

But by default the aforementioned filter handles only GET request.

org.eclipse.jetty.servlets.GzipFilter

// public void init
tmp=filterConfig.getInitParameter("methods");
        if (tmp!=null)
        {
            StringTokenizer tok = new StringTokenizer(tmp,",",false);
            while (tok.hasMoreTokens())
                _methods.add(tok.nextToken().trim().toUpperCase(Locale.ENGLISH));
        }
        else
            _methods.add(HttpMethod.GET.asString());

// public void doFilter()
if (!_methods.contains(request.getMethod()) || isExcludedPath(requestURI))
        {
            super.doFilter(request,response,chain);
            return;
        }