wiremock 1.35 proxy modifies requests before calling the actual web service about wiremock

[tomakehurst]

Agree it'd be better to accurately preserve all the incoming headers. The Apache HTTP client doesn't make explicitly making the Transfer-Encoding/Content-Length choice particularly easy, but it's definitely possible. I'll add it to the list.

[bluemarble]

Thanks very much for adding to your wish list. And, thank you for sharing such a useful piece of your work.

[tomakehurst]

Think I've got this fixed now. It's committed to master now if you want to build it and try it out.

I've got a few other changes in flight so I'll release it in the next few days when those are done.

[bluemarble]

Did a pull and build. I'm having the same problem building the standalone jar that others have mentioned. You mentioned in issue #26 that PGP is needed to allow the signing step to work.

Can I use a free software alternative instead, like GPG? What tools are you using?

[tomakehurst]

Try this:
$ gradle clean jarAll

That should skip the signing step but still produce the standalone JAR.

Failing that you could probably just delete these two bits from the build file:
apply plugin: 'signing'

signing { sign configurations.archives }

[bluemarble]

That did the trick! The chunked requests go through now.

I had to make another change to get things working. In my situation, the requests include a "Host:" header that needs to be passed through as well. One more quick hack got wiremock working as a proxy for this web service, on my machine anyway. I will fork the repo and see if I can make a cleaner fix. If so, I'll send a pull request so you can see the change.

That said, you have fixed the original issue. Thanks!

[tomakehurst]

I can fix the host header part easily enough. I'll add that before I release it.

[tomakehurst]

I've fixed the host header thing and released this now (it should arrive on m2 central in a few hours).

[yogamaha]

Hi @tomakehurst, Similar to the above problem I faced an issue with Proxy when the response returned by the actual service had the transfer-encoding header "chunked".

In the standalone mode, this header is lost & replaced by "content-length".
In the Webapp mode, there is no response from the service.

I resolved it for my local web app by overriding the implementation of DispatcherServlet & invoke httpServletResponse.getOutputStream().flush() if there is "chunked" header.

All these problems are with version 1.53

[tomakehurst]

Yeah, unfortunately because it buffers responses at the moment, you always end up with a known-length byte array and hence a Content-Length header being added by Jetty.

I'll have a look at fixing this in a future version I think, as it's useful to be able to test with both.

[yogamaha]

Thanks @tomakehurst for looking into my request.