Question: Does the WireMock send Content-Length response header

[o7g8]

Hello,

I need to make a response mock with a specific value of Content-Length header:

        [TestMethod]
        public async Task CheckMockHeaders() {
            var responseBody = @"<?xml version=""1.0""?><empty/>";
            mockServer
                .Given(Request
                    .Create()
                    .WithPath("/test")
                    .UsingPost())
                .RespondWith(Response
                    .Create()
                    .WithStatusCode(200)
                    .WithHeader("content-type", "text/xml")
                    .WithHeader("Content-Length", responseBody.Length.ToString())
                    .WithBody(responseBody));
            
            using (var httpClient = new HttpClient()) {
                var uri = mockServer.Urls.Single() + "test";
                using (var response = await httpClient.PostAsync(uri, new StringContent(""))) {
                    response.EnsureSuccessStatusCode();
                    Assert.IsTrue(response.Content.Headers.Any(x => x.Key == "Content-Length"));
                }
            }
        }

Unfortunately the Assert fails and the Content-Length is not part of response.Content.Headers.

I suspect problem might be in the fact that the server by default assigns header Transfer-Encoding: chunked.

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding

Data is sent in a series of chunks. The Content-Length header is omitted in this case and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format...

I was not able to assign my own Transfer-Encoding: identity. I will create a separate question about it.

WireMock.Net version 1.0.3.16.

[StefH]

For now I ignore these restricted headers in WireMock.Net:

• Accept
• Connection
• ContentLength
• ContentType
• Date
• Expect
• Host
• IfModifiedSince
• KeepAlive
• Range
• Referer
• TransferEncoding
• UserAgent
• ProxyConnection
• WWWAuthenticate

See also https://msdn.microsoft.com/en-us/library/78h415ay(v=vs.110).aspx

Did you check the original java implementation from WireMock to see if this is possible there?

[o7g8]

I haven't checked the Java implementation, so I don't know if it's possible there.
Regarding the https://msdn.microsoft.com/en-us/library/78h415ay(v=vs.110).aspx it says:

Tests whether the specified HTTP header can be set for the request.

But in my example, I attempt to set the Content-Length for the response, while WebHeaderCollection.IsRestricted concerns about requests.

The purpose of WireMock is to allow people to mock service responses, therefore, in my opinion, it's fair to expect that the library allows building a response with any kind of content.
The user may even want to build mocks with a wrong combination and/or content of response headers in order to test client's robustness.

Another thing which I have noticed inspecting the internals of mockServer: despite the Content-Length is not part of the actual response, the header is registered in the 'response' part of the server's logs. I think it's inconsistent behavior - the logs should reflect reality.

I also think that if WireMock has its own ideas about allowed and not allowed request and response headers, their content and their combinations, the server should crash in the case when the inconsistency is detected instead of silently ignoring it.

If we get back to my example: when you read the Given-RepondWith section you get an impression that the response does contain the Content-Length header, but in reality, it doesn't. And you won't notice it unless you check for it specifically. But I think you will agree that double checking of mocks/stabs state is not a best practice in tests.

[StefH]

You are correct. I think that I switched Request en Response headers in my implementation.

I had some troubles some time ago when setting the Content-Length header on the IOwinResponse or HttpResponse object.

I will check that code again, and keep you informed.

[StefH]

I've created a PR : you take a look and review this : #142

[StefH]

Solved, see NuGet 1.0.3.18