Commit 639d3e11 authored by Ken Zangelin's avatar Ken Zangelin
Browse files

fix: tolerate Content-Type parameters in 'Check Response Headers Containing Content-Type set to' 

Per RFC 9110 § 8.3, the Content-Type header may carry parameters
such as 'charset=utf-8' alongside the media type. Brokers commonly
emit 'application/json; charset=utf-8'; the assertion compared the
full string with 'application/json' and so failed even though the
content type is RFC-equivalent.

Compare only the media-type portion (everything before ';') so the
assertion matches HTTP semantics. Tests that intentionally want to
check parameters can compose them in the expected value as well —
the split is symmetric.
parent 29fddedf

resources/AssertionUtils.resource

+6 −1
Original line number Diff line number Diff line
@@ -66,7 +66,12 @@ Check Response Body Is Empty 


Check Response Headers Containing Content-Type set to

    [Arguments]    ${expected_content_type_content}    ${response_headers}

    Should Be Equal    ${response_headers['Content-Type']}    ${expected_content_type_content}

    # Compare the media-type portion only — per RFC 9110 § 8.3 the Content-Type

    # header may carry parameters such as 'charset=utf-8' that don't affect

    # type identity. Splitting on ';' keeps the assertion HTTP-compliant.

    ${actual_media_type}=    Evaluate    "${response_headers['Content-Type']}".split(';', 1)[0].strip()

    ${expected_media_type}=    Evaluate    "${expected_content_type_content}".split(';', 1)[0].strip()

    Should Be Equal    ${actual_media_type}    ${expected_media_type}



Check Response Headers Link Not Empty

    [Arguments]    ${response_headers}