Tom Akehurst

I would always recommend using stubs explicitly rather than relying on the default file serving approach, except for things like images/other static asserts. It's always possible to use a stub,...

A stub like this will work just fine: ```json { "request": { "method": "GET", "urlPath": "/api/v2/users/auth0|123456789/roles" }, "response": { "status": 200, "body": "{ \"message\": \"Put your response body here\" }"...

The stub filename doesn't have to be the same as the URL or any part of it. You can have a bunch of files called one.json, two.json etc. if you...

@maknesium were you using the current or legacy recorder?

`--record-mappings` is the legacy recorder, so I suggest trying the new one and seeing if you still have the same issue. https://wiremock.org/docs/record-playback/

If you hit the API you're proxying to directly do you get stream length = content-length = 23612 bytes? If so, the issue is possibly that the content-length header is...

@wind57 We can't just upgrade to Jetty 11 because (as you've pointed out) this would raise the minimum Java version to 11. I think the correct near-term solution would be...

@wind57 re self-signed certificates - this is a JDK17 problem rather than Jetty. The current WireMock version doesn't support certificate signing at the moment and we're looking for a long...

The Spring Cloud Contract team have been using `wiremock-jre8-standalone` for a while and apparently that means they avoid the Jetty 11 problem.

We'll aim to add Jetty 11 support in the next release, probably under a new artifact name since it'll take us up to Java 11+.