Request body is base64 encoded when the content-type is application/x-www-form-urlencoded

[pendsley]

The generated pact for a request with a body that is form-urlencoded is base64 encoded.

Pact definition

return builder.given("A user exists with credentials user///pass")
                .uponReceiving("A request to authenticate with correct credentials")
                .path("/login")
                .method("POST")
                .headers("Content-Type", MediaType.APPLICATION_FORM_URLENCODED_VALUE)
                .body("username=user&password=pass", MediaType.APPLICATION_FORM_URLENCODED_VALUE)
                .willRespondWith()
                .headers(ImmutableMap.of("Content-Type", MediaType.APPLICATION_JSON_VALUE))
                .status(200)
                .toPact();

Generated Pact

{
  "provider": {
    "name": "provider"
  },
  "consumer": {
    "name": "consumer"
  },
  "interactions": [
    {
      "description": "A request to authenticate with correct credentials",
      "request": {
        "method": "POST",
        "path": "/login",
        "headers": {
          "Content-Type": "application/x-www-form-urlencoded"
        },
        "body": "dXNlcm5hbWU9dXNlciZwYXNzd29yZD1wYXNz"
      },
      "response": {
        "status": 200,
        "headers": {
          "Content-Type": "application/json"
        }
      },
      "providerStates": [
        {
          "name": "A user exists with credentials user///pass"
        }
      ]
    }
  ],
  "metadata": {
    "pactSpecification": {
      "version": "3.0.0"
    },
    "pact-jvm": {
      "version": "4.1.6"
    }
  }
}

[pendsley]

I can override it manually by setting pact.content_type.override.application.x-www-form-urlencoded=text, but that seems like a workaround. I don't think it should default to being encoded.

It looks like the issue might be in ContentType.isBinaryType().

registry.getSupertype("application/x-www-form-urlencoded") is resolving to application/octet-stream

[pulgupta]

I am also facing the same issue body is getting base64 encoded. The header which I am using is Content-Type=application/x-www-form-urlencoded;charset=UTF-8 and but for this my tests.

[uglyog]

4.1.7 has been released with this fix