Tag: HTTP Server-Side Errors

A Short Note – How To Debug HTTP Server-Side Errors In iOS ?

Hello Readers, CoolMonkTechie heartily welcomes you in A Short Note Series (How To Debug HTTP Server-Side Errors In iOS ?).

In this note series, we will understand HTTP server-side errors and how to debug them in iOS.


So Let’s begin.


Overview

Apple’s HTTP APIs report transport errors and server-side errors:

  • A transport error is caused by a problem getting our request to, or getting the response from, the server. These are represented by a NSError value, typically passed to our completion handler block or to a delegate method like urlSession(_:task:didCompleteWithError:). If we get a transport error, investigate what’s happening with our network traffic.
  • A server-side error is caused by problems detected by the server. Such errors are represented by the statusCode property of the HTTPURLResponse.

The status codes returned by the server aren’t always easy to interpret. Many HTTP server-side errors don’t give us a way to determine, from the client side, what went wrong. These include the 5xx errors (like 500 Internal Server Error) and many 4xx errors (for example, with 400 Bad Request, it’s hard to know exactly why the server considers the request bad).


Print the HTTP Response Body

In this section, we explain how to debug these server-side problems.

Sometimes, the error response from the server includes an HTTP response body that explains what the problem is. Look at the HTTP response body to see whether such an explanation is present. If it is, that’s the easiest way to figure out what went wrong. For example, consider this standard URLSession request code.

URLSession.shared.dataTask(with: url) { (responseBody, response, error) in
    if let error = error {
        // handle transport error
    }
    let response = response as! HTTPURLResponse
    let responseBody = responseBody!
    if !(200...299).contains(response.statusCode) {
        // handle HTTP server-side error
    }
    // handle success
    print("success")
}.resume()

A server-side error runs the line labeled handle HTTP server-side error. To see if the server’s response contains any helpful hints what went wrong, add some code that prints the HTTP response body.

        // handle HTTP server-side error
        if let responseString = String(bytes: responseBody, encoding: .utf8) {
            // The response body seems to be a valid UTF-8 string, so      print that.
            print(responseString)
        } else {
            // Otherwise print a hex dump of the body.
            print(responseBody as NSData)
        }


Compare Against a Working Client

If the HTTP response body doesn’t help, compare our request to a request issued by a working client. For example, the server might not fail if we send it the same request from:

  • A web browser, like Safari
  • A command-line tool, like curl
  • An app running on a different platform

If we have a working client, it’s relatively straightforward to debug our problem:

  1. Use the same network debugging tool to record the requests made by our client and the working client. If we’re using HTTP (not HTTPS), use a low-level packet trace tool to record these requests. If we’re using HTTPS, with Transport Layer Security (TLS), we can’t see the HTTP request. In that case, if our server has a debugging mode that lets us see the plaintext request, look there. If not, a debugging HTTP proxy may let us see the request.
  2. Compare the two requests. Focus on the most significant values first.
    • Do the URL paths or the HTTP methods match?
    • Do the Content-Type headers match?
    • What about the remaining headers?
    • Do the request bodies match?
    • If these all match and things still don’t work, we may need to look at more obscure values, like the HTTP transfer encoding and, if we’re using HTTPS, various TLS parameters.
  3. Address any discrepancies.
  4. Retry with our updated client.
  5. If things still fail, go back to step 1.


Debug on the Server

If we don’t have access to a working client, or we can’t get things to work using the steps described in the previous section, our only remaining option is to debug the problem on the server. Ideally, the server will have documented debugging options that offer more insight into the failure. If not, escalate the problem through the support channel associated with our server software.


Conclusion

In this note series, we understood HTTP server-side errors and how to debug them in iOS.

Thanks for reading! I hope you enjoyed and learned about HTTP Server-side Concept in iOS. Reading is one thing, but the only way to master it is to do it yourself.

Please follow and subscribe to the blog and support us in any way possible. Also like and share the article with others for spread valuable knowledge.

You can find Other articles of CoolmonkTechie as below link :

You can also follow other website and tutorials of iOS as below links :

If you have any comments, questions, or think I missed something, leave them below in the comment box.

Thanks again Reading. HAPPY READING !!???

Exit mobile version