request.HTTPBody is always nil in custom matcher

[paulyoung]

I'm setting the HTTPBody property of an NSMutableURLRequest and trying to do some comparison on it inside of a custom matcher.

However, the property's value is always nil by the time the request reaches the matcher despite it being set prior to that.

[kylef]

Hi @paulyoung, just to confirm. you're setting the property and then making a request with NSURLConnection/NSURLSession?

Would you be able to check if passing your request directly to MockingjayProtocol's canInitWithRequest method results in the HTTPBody still being there.

MockingjayProtocol.canInitWithRequest(request)

[paulyoung]

@kylef I can confirm that inside of canInitWithRequest(request) the HTTPBody is nil.

However, I just made this change and now everything works as expected: the-grid/Disc@02b31d9

In any case, this issue can be closed. Thanks for looking into it!

[paulyoung]

So it appears that this issue wasn't actually resolved. I think what was happening was the actual request was being made, and now that request is no longer valid so a test started failing.

Where session is NSURLSession.sharedSession(), here's some info from right before the request is passed as session.dataTaskWithRequest(request):

(lldb) po request
<NSMutableURLRequest: 0x100723390> { URL: https://passport.thegrid.io/login/authorize/token }

(lldb) po request.HTTPBody
▿ Optional(<7b22636f 6465223a 22636f64 65222c22 636c6965 6e745f69 64223a22 6964222c 22636c69 656e745f 73656372 6574223a 22736563 72657422 2c226772 616e745f 74797065 223a2261 7574686f 72697a61 74696f6e 5f636f64 65227d>)

Here's the same thing inside my custom matcher:

(lldb) po request
<NSURLRequest: 0x102046500> { URL: https://passport.thegrid.io/login/authorize/token }

(lldb) po request.HTTPBody
nil

[paulyoung]

Here are the relevant test case:

https://github.com/the-grid/Disc/blob/dd74d66dad519fa6f36ca62e689c52e592ead607/DiscTests/Networking/Authorization/GetAccessTokenSpec.swift#L40

and matcher:

https://github.com/the-grid/Disc/blob/dd74d66dad519fa6f36ca62e689c52e592ead607/DiscTests/Helpers/MockingjayMatchers.swift#L29-L33

[kylef]

Thats for the additional information.

Had a look into this and I can confirm this is how it's behaving, after doing some digging it does seem like either an bug in NSURLSession or how NSURLSession is designed. Mockingjay registers as an NSURLProtocol and the first method that NSURLSession will call on the protocol is canInitWithRequest: to try and find the protocol that can handle this request.

I've also found this note from a README from OHHTTPStubs (the popular Objective-C alternative) which mentions the same problem. I've found a related discussion inside OHHTTPStubs:

This leads to NSURLProtocol's +canInitWithRequest: method to be called with a request with an empty HTTPBody, because HTTPBody and HTTPBodyStream properties are handled internally and specifically by Apple for the HTTP protocol (for the specific internal NSURLProtocol originally managing the "http://" scheme by Apple).

I'm not really sure how we can go about adding support for this.

[kylef]

Additionally, found a related rdar://15993891 which includes a comment stating that this is not how the documentation says it should work:

Worth nothing that Apple have demonstrated this field should be available in their example project:
https://developer.apple.com/library/ios/samplecode/CustomHTTPProtocol/Listings/CustomHTTPProtocol_Core_Code_CanonicalRequest_m.html#//apple_ref/doc/uid/DTS40013653-CustomHTTPProtocol_Core_Code_CanonicalRequest_m-DontLinkElementID_8

[kylef]

Interesting workaround: https://github.com/AliSoftware/OHHTTPStubs/wiki/Testing-for-the-request-body-in-your-stubs

[paulyoung]

Thanks again for looking into this! I employed the "transparent" workaround.

Feel free to close this issue or leave open as you see fit.