AFNetworking 404 response for valid url

1
votes

I'm using AFNetworking 2.0 accessing (AFHTTPRequestOperation *) GET for a multiplicy of URLs for public web sites. 99% of the calls work fine but the odd one returns 404 (Not Found). An example is URLString = "http://feeds.wired.com/wired/index" which works (without a redirect) with all of the following methods:

  • Browser
  • Low-level iOS call [NSURLConnection sendAsynchronousRequest:URLString ...] from Objective-C code
  • $.ajax call via jQuery from JavaScript

However, (AFHTTPRequestOperation *) GET returns 404 (without a redirect).

These are the headers I'm sending for both (AFHTTPRequestOperation *) GET and $.ajax (NSURLConnection works without any headers at all).

  • User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko
  • Accept: text/html, application/xhtml+xml, /
  • Accept-Encoding: gzip, deflate
  • DNT: 1
  • Cache-Control: no-cache

I'm quite sure there is something weird with the response from http://feeds.wired.com/wired/index which either AFNetworking or some lower level iOS NS method is choking on but I can't figure it out from rudimentary profiling of the code execution.

I'd like AFNetworking to be flexible enough to handle anything I throw at it that browsers, low-level iOS and jQuery $.ajax can handle.

Does anyone know the potential source of this issue and how AFNetowking could be parameterized of modifed to accomodate it?

1
afnetworkingafnetworking-2

1 Answers

1
votes

I have discovered the problem here. If (AFHTTPRequestOperation *) GET is provided a value for "parameters" that is an empty dictionary, it appends a "?" to the end of the URL which some websites don't like and respond to with "404". The solution is to never provide an empty dictionary. Instead, provide "nil" if there are no parameters.

Personally I think this is an AFNetworking bug, but the workaround is simple.