Empty Request Body

[ghost]

A very strange issue that baffles me completely. Using WireMock in a test case with usage similar to

stubFor(get(urlEqualTo("/some/thing"))
        .willReturn(aResponse()
            .withHeader("Content-Type", "application/json")
            .withBody(bigLumpOfJSON)));

then the code under test was convinced that the body was empty. Under real use, the code is cheerfully seeing the expected JSON body, and flipping to use REST-Driver allowed me to successfully stub. The only thing I could think of was that it arises from the way that WireMock is writing to the output stream and Apache HTTP Client is trying to read from the input stream. The code under test uses HttpClient to handle the request, roughly as follows:

try {
    final HttpGet request = new HttpGet(statusUrl.toURI());
    final HttpResponse httpResponse = httpClient.execute(request);
    final int statusCode = getResponseCode(httpResponse);

    if (HttpStatus.SC_OK == statusCode) {
        final HttpEntity entity = httpResponse.getEntity();

        if (entity == null) {
            throw new ServiceUnavailable("No content in the response");
        } else {
            final String body = EntityUtils.toString(entity, "UTF-8");
            final Map<String, Object> statusData = mapper.readValue(body, Map.class);
            return Status.valueOf((String) statusData.get("status"));
        }

    } else {
        throw new ServiceUnavailable("Server Returned " + statusCode);
    }
} catch (URISyntaxException urie) {
    throw new ServiceUnavailable("invalid URL", urie);
} catch (IOException ioe) {
    throw new ServiceUnavailable("IO failure", ioe);
}

Debugging I could see that there was a non-null entity coming out of the response (yay!) but then the EntityUtils.toString() was returning an empty string. Ferreting into that a bit further, I could see that the various levels of HttpResponse contained an InputStream that was very definitely empty.

I'm more than happy to continue trying to get to the bottom of this issue, as the framework looks like a perfect match for our needs. It's just that my forehead is still sore from beating it on the desk last week before switching to REST-Driver.

[tomakehurst]

Hi,

Would you mind sending me the version of WireMock you're using, whether you're using the standalone JAR and the version of the Apache HTTP client you're using?

Also does your bigLumpOfJson have any unusual characters in it? And is it very large?

Many thanks,
Tom

[ghost]

No worries

HttpClient is 4.2.3 GA
WireMock is 1.28 - I was not using the standalone JAR, I was driving it around with JUnit

the bigLumpOfJson is only a few hundred bytes in the test case:

{"serviceName":"AttributionEngine","hostName":"localhost","version":"1.0",
"startTime":"20130221T133518Z","status":"ACTIVE","intervals":60,"intervalSize":"minutes",
"serverTime":"20130221T133732Z","javaVersion":"1.7.0_10","counters":[]}

[tomakehurst]

I've tried to replicate this issue as closely as possible based on the info and code you've given me and everything seems to be working normally. Here's the full test case I used. Perhaps you can spot a crucial difference from what you've done:

package wiremock.test;


import com.github.tomakehurst.wiremock.junit.WireMockRule;
import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.HttpStatus;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.DefaultHttpClient;
import org.apache.http.util.EntityUtils;
import org.junit.Rule;
import org.junit.Test;

import static com.github.tomakehurst.wiremock.client.WireMock.*;
import static junit.framework.Assert.assertFalse;

public class AppTest {

    @Rule
    public WireMockRule wireMockRule = new WireMockRule();

    @Test
    public void test() throws Exception {
        String bigLumpOfJSON = "{\"serviceName\":\"AttributionEngine\",\"hostName\":\"localhost\",\"version\":\"1.0\",\n" +
                "\"startTime\":\"20130221T133518Z\",\"status\":\"ACTIVE\",\"intervals\":60,\"intervalSize\":\"minutes\",\n" +
                "\"serverTime\":\"20130221T133732Z\",\"javaVersion\":\"1.7.0_10\",\"counters\":[]}";

        stubFor(get(urlEqualTo("/some/thing"))
                .willReturn(aResponse()
                        .withHeader("Content-Type", "application/json")
                        .withBody(bigLumpOfJSON)));


        final HttpGet request = new HttpGet("http://localhost:8080/some/thing");
        final HttpResponse httpResponse = new DefaultHttpClient().execute(request);
        final int statusCode = httpResponse.getStatusLine().getStatusCode();

        if (HttpStatus.SC_OK == statusCode) {
            final HttpEntity entity = httpResponse.getEntity();

            if (entity == null) {
                throw new RuntimeException("No content in the response");
            } else {
                final String body = EntityUtils.toString(entity, "UTF-8");

                System.out.println(body);
                assertFalse(body.isEmpty());
            }

        } else {
            throw new RuntimeException("Server Returned " + statusCode);
        }
    }
}

[ghost]

This is profoundly weird. I'm starting to think that the problem is on the HttpClient end, and there is some weird emergent behaviour arising out of the intersection of Ubuntu, 1.7.0_10 and a slightly wonky network configuration. I will keep banging on this to see if I can get any further.

[tomakehurst]

Right, I'm on a Mac so unfortunately I can't replicate that part. Please
let me know if it does turn out to be a bug or some kind of OS interaction

• trying to make it as robust as possible!

Thanks,
Tom

On 27 February 2013 09:41, Robert Hook notifications@github.com wrote:

This is profoundly weird. I'm starting to think that the problem is on the
HttpClient end, and there is some weird emergent behaviour arising out of
the intersection of Ubuntu, 1.7.0_10 and a slightly wonky network
configuration. I will keep banging on this to see if I can get any further.

—
Reply to this email directly or view it on GitHubhttps://github.com/tomakehurst/wiremock/issues/14#issuecomment-14164874
.

[ghost]

Will do. I will work with the test case you've built above on several different platforms and see what comes out.

ADDENDUM: the plot thickens - the test case above is now working on the combination of Ubuntu and 1.7.0_10, strongly suggesting some wonkiness in the network configuration has become involved.

ADDENDUM 2: I loathe Heisenbugs (http://www.catb.org/jargon/html/H/heisenbug.html). I cannot reproduce this fault at all now. There are two things that have changed: Commons IO was bumped from 2.3 to 2.4, and our network is not as flaky as it was on Thursday when the problem manifested. I will continue to monitor the behaviour in our environment, but at this stage think that the issue can be closed off as "problem exists between keyboard and chair".

I have moved our testing fully to WireMock, and directed my team to run forward with it - it's exactly right solution for our requirements.

[tomakehurst]

Thanks for the feedback. Good to hear its proving to be useful!

HTTPS support to be released shortly if that's of any interest.