Well, I seem to have hit a dead end with the header verification. Relevant part of pact looks as follows

"response": {

        ...

        "headers": {
          "Last-Modified": "Sun, 12 Mar 2023 01:21:35 GMT"
        },

        ...

       "matchingRules": {
          "$.headers.Last-Modified": {
            "match": "regex",
            "regex": "^[A-Za-z]{3},\\s\\d{2}\\s[A-Za-z]{3}\\s\\d{4}\\s\\d{2}:\\d{2}:\\d{2}\\sGMT$"
          },

          ...

        }

      }

  ...

  "metadata": {
    "pactSpecification": {
      "version": "2.0.0"
    }
  }

I think the regular expression is correct, since I have tested it many times using various tools:

# The date and time format used in the Last-Modified header according to
# RFC 7231 is described in section 7.1.1.1.
#
# Examples:
#
#    Last-Modified: Mon, 12 Feb 1996 11:36:28 GMT
#    Last-Modified: Sat, 11 Mar 2023 21:56:41 GMT
#
LAST_MODIFIED_REGEX = r'^[A-Za-z]{3},\s\d{2}\s[A-Za-z]{3}\s\d{4}\s\d{2}:\d{2}:\d{2}\sGMT$'

But when I try to verify it, it somehow compares for an exact match, without using a regular expression:

Pending Failures:

1) Verifying a pact between ProductServiceClient and ProductService Given there is a product with ID 1 - a request for a product
    1.1) includes header 'Last-Modified' with value 'Sun'
           Expected header 'Last-Modified' to have value 'Sun' but was 'Sun'
           Expected header 'Last-Modified' to have value '12 Mar 2023 01:21:35 GMT' but was '12 Mar 2023 01:21:52 GMT'

The difference in seconds: 35 vs 52. And it fails because in pact I have • “Sun, 12 Mar 2023 0121*35* GMT” but providers returns • “Sun, 12 Mar 2023 0121*52* GMT” I use the same approach ( using regular expression test) for other headers like ETag, Content-Type and they are fine, verification passes as expected. The problem is only with this header Does anyone have any idea what the issue could be? Of course, I can create the required date on the provider side using request to /_pact/provider_states. However, in this case all my efforts will be to provide an exact match, and I would like to use the pattern here

I think this is the bug with the header parsing where it’s splitting on

,

. Looks like a bug in pact-reference, probably. What provider verification are you using?

I use rust cli verifier

Yes, verification takes part on the server side, but it is still is driven by pact. Most implementations now use the rust core- but not all of them

Thanks for the bug report - it looks like my colleague has picked this up today so we’ll get it into the JS and other projects once it is fully released.