citrusframework / yaks

YAKS is a platform to enable Cloud Native BDD testing on Kubernetes
Apache License 2.0
82 stars 27 forks source link

HTTP header name verification should be case insensitive #472

Closed wrungel closed 10 months ago

wrungel commented 1 year ago

Context

Use yaks HttpClientSteps to assert HTTP headers and body in response on different test environments.

Problem

On some of our test environments HTTP headers are modified by an intermediate system. In our case we use OpenShift Cluster with ingress, which converts all HTTP header names to lower case. According to RFC 2616 - "Hypertext Transfer Protocol -- HTTP/1.1", Section 4.2, "Message Headers", the HTTP header names are case insensitive. But Yaks while verifying the headers does not consider the case insensivity. This makes it hard to write environment independent tests.

Another problem is, that the the step And expect HTTP response body is always ignored if the step Then expect HTTP response header Content-Type="..." is not defined. See HttpClientSteps.java#L191 So we can also not verify response body at all because header verification always fails.

Example:

The following scenario fails on some environment in step Then expect HTTP response header Content-Type="application/xml;charset=UTF-8".

  Scenario: HTTP response headers are case sensitive

    Given URL: http://server
    And HTTP request header Content-Type="application/json"
    And HTTP request body
    """
    {"hello": "world"}
    """
    When send POST /api/test
    Then expect HTTP response header Content-Type="application/xml;charset=UTF-8"
    And expect HTTP response body
    """
    <errorResponse>
      <errorCode>123</errorCode>
    </errorResponse>
    """
    And receive HTTP 400 BAD_REQUEST

What I wish

It would be great to have the following features in Yaks / Citrusframework

christophd commented 10 months ago

Citrus already provides a setting to enable case insensitive header validation. We just need to make this settable via Cucumber step in YAKS.

I am not aware of any mandatory Content-Type header validation. There must be something else going wrong in your scenario.