OHHTTPStubs icon indicating copy to clipboard operation
OHHTTPStubs copied to clipboard

DISCUSSION: No way to stub server response which will lack a Content-Length header

Open mikelupo opened this issue 7 years ago • 3 comments

This really isn't a bug, it's more of how OHTTPSTubs is currently designed. The OHHTTPStubsResponse object will automatically add a Content-Length header if you didn't specify one in the OHHTTPStubsResponse.

return [OHHTTPStubsResponse responseWithFileAtPath:OHPathForFile(@"Sample-Video.mp4", [weakSelf class])
    statusCode:200 
    headers:@{
														
            @"Server":@"openresty/1.7.4.1",
            @"ETag" :@"3c8f0eb7eae10fd2b42eb41d4e0568e7:1459461318",
            @"Last-Modified" : @"Sat, 27 Apr 2013 00:44:54 GMT",
            @"Content-Type" : @"video/mp4",
//            @"Content-Length" : 12345,
            @"Expires" : @"Tue, 1 Jan 2036 18:43:49 GMT",
            @"Vary" : @"Accept-Encoding",
            @"Date" : @"Fri, 24 Jun 2016 20:54:02 GMT"
}];

@AliSoftware, what do you think about if we can set the Content-Length to [NSNull null] and check for that in the OHHTTPStubsResponse object upon its creation, to conditionally ignore the Content-Length header? We actually have a case that we encountered where a server MAY fail to send the Content-Length header on some multi-part stuff. I'd like a way to test this. Easy enough to do. Are you open to a PR that allows this?

mikelupo avatar Dec 22 '17 15:12 mikelupo

Hi Mike

I get the problem but I'm not sure I like using some magical NSNull value (feels more like a hack to me)

What about adding an additional property like @property(assign) BOOL computeContentLength to OHHTTPStubsResponse, defaulting to YES (and thus defaulting to the current behavior), but which you could set to NO if needed before returning your OHHTTPStubsResponse?

AliSoftware avatar Dec 22 '17 15:12 AliSoftware

Also I'm not sure that the Swift generated API would explicitly allow Optional values so from Swift we couldn't replace that magical NSNull you suggest to be nil (except changing the headers signature to accept nil values but I don't think that would be the right call?). while a dedicated property feels more compatible with Swift API here too

AliSoftware avatar Dec 22 '17 15:12 AliSoftware

I'll consider that in our own implementation here at Akamai first. 👍

mikelupo avatar Dec 22 '17 16:12 mikelupo