Current coverage is 74.20%

Merging #3292 into master will decrease coverage by -0.25% as of f1c6025

@@            master   #3292   diff @@
======================================
  Files            5       5       
  Stmts         3002    3004     +2
  Branches         0       0       
  Methods                          
======================================
- Hit           2235    2229     -6
  Partial          0       0       
- Missed         767     775     +8

Review entire Coverage Diff as of f1c6025

Powered by Codecov. Updated on successful CI builds.

cc @kylef @cnoon @jshier @0xced

Any thoughts here on this patch?

Hey @kcharwood, sorry for not getting back to you sooner.

It's a bit difficult for me to tell exactly what all the moving pieces are here in this logic. I made a very similar type change to Alamofire about 4 months ago to support 204 and 205 cases properly. I stopped validating the content type if there was no data returned which you can see here. The reason was that iOS will "infer" a content-type even if one isn't returned by the server. I was seeing "text/plain" being reported as the MIMEType even though nothing was returned. Because of this behavior, the only consistent way around the problem that I could find was to just ignore the content type validation if no data was returned. That made things simple and seemed like a reasonable tradeoff.

I can't tell if that's exactly what you're doing here, but that ended up being my reasoning.

My check here is adding an additional check to prevent response type validation if there is no MIME type and the response data length == 0.

The inferred content type however may throw a wrench in that?