Content-Encoding vs. Content-encoding
version: SoapUI 4.6.4
SoapUI appears to make a distinction between these two incarnations of the same header which differ only in case. More specifically, 'Content-Encoding: gzip' in a response is properly decompressed and displayed by SoapUI whereas a 'Content-encoding: gzip' response does NOT get decompressed. Rather the uncompressed binary response is displayed in the raw response window.
Per the specs, this doesn't appear to behave correctly:
From RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", ยง4.2, "Message Headers":
Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
I can verify the content in both cases is compressed properly. Also if i disable compressed responses from the preferences pane the response is properly grocked.
Is this a known issue? Is there a way to allow SoapUI to honor response headers regardless of case? Let me know what you think. Thanks!
=bwh=
SoapUI appears to make a distinction between these two incarnations of the same header which differ only in case. More specifically, 'Content-Encoding: gzip' in a response is properly decompressed and displayed by SoapUI whereas a 'Content-encoding: gzip' response does NOT get decompressed. Rather the uncompressed binary response is displayed in the raw response window.
Per the specs, this doesn't appear to behave correctly:
From RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", ยง4.2, "Message Headers":
Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
I can verify the content in both cases is compressed properly. Also if i disable compressed responses from the preferences pane the response is properly grocked.
Is this a known issue? Is there a way to allow SoapUI to honor response headers regardless of case? Let me know what you think. Thanks!
=bwh=
