OHHTTPStubs
OHHTTPStubs copied to clipboard
DISCUSSION: No way to stub server response which will lack a Content-Length header
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?
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
?
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
I'll consider that in our own implementation here at Akamai first. 👍