Should it be possible to use matchers in content-types of a request? (V3 .59 & .60) I get

PactffiWithBody(arg 2) expected a string

As in, a header?

I think its was limited first time in https://github.com/pact-foundation/pact-js/commit/d04ab2020df9f97082160c224d9ace9b79d96cd4#diff-b538a99e9d72281381eb29[…]2093884006c52860a6bc248R103 currently https://github.com/pact-foundation/pact-js/blob/156886fde85d2a1fa217a68db69fd876d3a76001/src/v3/types.ts#L73

Matchers are explicitly allowed in headers: https://github.com/pact-foundation/pact-specification/tree/version-3

this works for me

provider.uponReceiving(`as '${user}', a PUT request to upload a file to '${file}'`)
    .withRequest({
      method: 'PUT',
...
      contentType: 'text/plain; charset=utf-8'
    })
    .willRespondWith(response)

but this not

provider.uponReceiving(`as '${user}', a PUT request to upload a file to '${file}'`)
    .withRequest({
      method: 'PUT',
...
      contentType: MatchersV3.regex('text/plain(;()?charset=(utf|UTF)-8)?', 'text/plain; charset=utf-8')
    })
    .willRespondWith(response)

It should definitely be supported. Is the error on the consumer or provider side?

running the consumer tests I get

PactffiWithBody(arg 2) expected a string

sorry, you did say that Artur

If that supposed to be supported and its a limitation I can try to look into it today, let's see what I find

OK just looked. This is the consumer request content type, right? Any reason you need a matcher there? In any case, the

contentType

property cannot be a matcher (see the type definition). It says “this is the content type of this request”. It’s an optional field though.

I need a matcher there because different versions of the provider answer differently, but both inside of the specs. e.g. upper/lowercase

In your example above it’s the consumer, but I assume you want the provider also? If so, same deal.

'text/xml; charset=utf-8'

is valid but also

'application/xml; charset=UTF-8'

e.g. this sort of thing

withResponse: {
              headers: { "Content-Type": MatchersV3.regex('text/plain(;()?charset=(utf|UTF)-8)?', 'text/plain; charset=utf-8') },
            },

yes finally its about the provider Thanks I will try that

yep, we do support it - just omit

contentType

all together and use the standard header matching

yes, why not. at the end of the day its just a header like any other

Oh! Pact V3 is supposed to understand the content type anyway

Matchers are still supposed to work in headers, so there’s still a bug

Artur wasn’t using it on the headers but an optional

contentType

field on the response object. That doesn’t take a matcher, but the exact content type of the request / response

also with xml?

it should, yes

works fine with putting the content-type only in the header. I cannot remember why I started to use the

contentType

parameter maybe it was because of this issue https://github.com/pact-foundation/pact-js/issues/575

might have been! I’m still a little hazy on what should be explicitly set by the user in a pact test (via something like

contentType

- not the header), implicitly via content sniffing in the core, or via the usual header match.

here the next issue, maybe related I have this interaction in the JSON file

"description": "as 'admin', a POST request to create a user",
"request": {
  "body": "password=1234&userid=testUser1",
  "headers": {
    "Content-Type": "application/x-www-form-urlencoded",
    "authorization": "Basic YWRtaW46YWRtaW4="
  },
......

with .59 it sends me the data as expected with .60 it converts the body to a JSON string (see wireshark screenshot)