NSMutableURLRequest with parameter - cannot parse response

Question

I am trying to create a connection to a URL that prints out JSON code that is then parsed and processed. My URL has a parameter called bypass. The URL looks like this:

http://www.getchanged.net/json.asp?bypass=MIGCBgkrBgEEAYI3WAOxxx

I did not manage to solve this issue as it always says Connection failed with error: cannot parse response

NSURL *aUrl = [NSURL URLWithString:@"http://www.getchanged.net/json.asp"];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:aUrl cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:60.0];

[request setHTTPMethod:@"GET"];
NSString *postString = @"bypass=MIGCBgkrBgEEAYI3WAOxxx";
[request setHTTPBody:[postString dataUsingEncoding:NSUTF8StringEncoding]];

Error:

2014-10-29 21:43:39.529 TestMap[57987:1931535] Connection failed with error: cannot parse response

What is wrong here?

Please note: I replaced the bypass hash a bit because it contains sensible data. The website works and is printing out JSON output.

Answer 1

A couple of observations:

1. The key issue is that you are issuing a GET request, but supplying the bypass parameter in the body of the request. For POST requests, the parameters should be added to the body, but for GET requests, it should be added to the URL.

2. If this bypass key could ever contain reserved characters (such as spaces, &, +, etc.), you'd want to percent-escape the value you're supplying for bypass. If you are guaranteed that it will be only alphanumeric, you can get away without percent escaping it, but as a general rule, you should always percent-escape HTTP parameters.

3. While point #1 will probably resolve this issue, sometimes web services will expect certain header fields to be set. For example, it is common to set Content-Type header of the request (e.g., this looks like the Content-Type of the request should be application/x-www-form-urlencoded).

4. You say that you are receiving an error message, "Connection failed with error: cannot parse response". You haven't shown us the code that is producing this error, but I presume this was generated when your code tried to parse a response as JSON when it wasn't.

   In the future, when diagnosing these issues, I find it useful to actually examine the details of the response. Notably, the header of the response will be contained in the NSURLResponse (which will actually be a NSHTTPURLResponse which has a statusCode numeric value which can be very illuminating). The body of the response will often be a string representation of the error (often when a web service fails it generates text or HTML description of the error).

   Whenever you get errors like this in the future, always look at the statusCode and the text of whatever the server returned, as that would help you diagnose what's going on. It will be more informative than a generic "I cannot parse the response" message.

5. If you have a web interface that works, and an application interface that doesn't, it's sometimes useful to use a tool like Charles to observe the request generated by the web browser and compare that to the request generated by the app. This can be invaluable when diagnosing these sorts of issues.

   Also, if you use something like Charles, this allows you to manually inspect the status code and text response of the server which I suggested you might handle programmatically in point #4.