Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POST request without content-type sends empty body #386

Closed
mefellows opened this issue Feb 12, 2024 · 3 comments
Closed

POST request without content-type sends empty body #386

mefellows opened this issue Feb 12, 2024 · 3 comments
Labels
smartbear-supported SmartBear engineering team will support this issue. See https://docs.pact.io/help/smartbear

Comments

@mefellows
Copy link
Member

Given this pact file:

{
  "consumer": { "name": "thing" },
  "provider": { "name": "other-thing" },
  "interactions": [{
      "description": "a request to the other thing",
      "request": {
        "method": "post",
        "path": "/endpoint",
        "body": {
          "this": "field"
        }
      },
      "response": {
        "status": 200
      }
    }],
  "metadata": {
    "pactSpecification": {
      "version": "2.0.0"
    }
  }
}

No body will be sent via the verifier. When:

        "headers": {
          "Content-Type": "application/json"
        },

is added to the request section of the pact, it will send it.

This makes some sort of sense, however it raises the question as to how we should provide this feedback, especially in the FFI world where the pact is built up gradually where such validations could only happen later on.

Perhaps a warning could be emitted during the "start mock server" stage or perhaps also even on the provider side during verification?

@rholshausen rholshausen added the smartbear-supported SmartBear engineering team will support this issue. See https://docs.pact.io/help/smartbear label Feb 19, 2024
Copy link

🤖 Great news! We've labeled this issue as smartbear-supported and created a tracking ticket in PactFlow's Jira (PACT-1837). We'll keep work public and post updates here. Meanwhile, feel free to check out our docs. Thanks for your patience!

@rholshausen
Copy link
Contributor

I am unable to replicate this. If this behavior is happening, it is not in the Rust core.

Given that Pact file, here is the request made by the verifier:

2024-02-17T22:41:11.379092Z  INFO pact_verifier::provider_client: Sending request HTTP Request ( method: POST, path: /endpoint, query: None, headers: None, body: Present(16 bytes) )
2024-02-17T22:41:11.379137Z DEBUG pact_verifier::provider_client: body:
7B2274686973223A226669656C64227D (16 bytes)

and then by the mock server:

2024-02-17T22:41:11.380607Z  INFO pact_mock_server::hyper_server: Received request POST /endpoint
2024-02-17T22:41:11.380633Z DEBUG pact_mock_server::hyper_server:
      ----------------------------------------------------------------------------------------
       method: POST
       path: /endpoint
       query: None
       headers: Some({"content-length": ["16"], "host": ["127.0.0.1:43441"], "accept": ["*/*"], "accept-encoding": ["gzip", "deflate"]})
       body: Present(16 bytes)
      ----------------------------------------------------------------------------------------

2024-02-17T22:41:11.380732Z  INFO pact_matching: comparing to expected HTTP Request ( method: POST, path: /endpoint, query: None, headers: None, body: Present(19 bytes)
)
2024-02-17T22:41:11.380747Z DEBUG pact_matching:      body: '7B202274686973223A20226669656C6422207D (19 bytes)'
2024-02-17T22:41:11.380751Z DEBUG pact_matching:      matching_rules: MatchingRules { rules: {PATH: MatchingRuleCategory { name: PATH, rules: {} }} }
2024-02-17T22:41:11.380759Z DEBUG pact_matching:      generators: Generators { categories: {} }
2024-02-17T22:41:11.380805Z TRACE pact_matching: plugin_data = {}
2024-02-17T22:41:11.380869Z TRACE matcher_is_defined{matchers=MatchingRuleCategory { name: PATH, rules: {} }}: pact_models::matchingrules: matcher_is_defined: for category path and path [] -> false
2024-02-17T22:41:11.380885Z TRACE matcher_is_defined{matchers=MatchingRuleCategory { name: PATH, rules: {} }}: pact_matching: return=false
2024-02-17T22:41:11.380920Z DEBUG matches_with{self="/endpoint" actual="/endpoint" matcher=Equality cascaded=false}: pact_matching::matchers: String -> String: comparing '/endpoint' to '/endpoint' ==> true cascaded=false matcher=Equality
2024-02-17T22:41:11.380940Z DEBUG pact_models::content_types: Detecting content type from contents: '{ "this": "field" }'
2024-02-17T22:41:11.395831Z DEBUG pact_models::content_types: Detecting content type from contents: '{"this":"field"}'
2024-02-17T22:41:11.395879Z DEBUG pact_matching: expected content type = 'application/json', actual content type = 'application/json'
2024-02-17T22:41:11.396311Z DEBUG pact_matching: content type header matcher = 'RuleList { rules: [], rule_logic: And, cascaded: false }'

As there is no content type, the mock server automatically detects it as JSON.

It may be the client language HTTP code is not reading the body if there is no content type.

@mefellows
Copy link
Member Author

hmm thanks for confirming this. Also silly me, I haven't linked this to the source of the request. Off to search github issues / slack!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
smartbear-supported SmartBear engineering team will support this issue. See https://docs.pact.io/help/smartbear
Projects
None yet
Development

No branches or pull requests

2 participants