Troubleshooting WooCommerce HTTP Requests

The WordPress codebase exposes some extraordinarily useful hooks for troubleshooting within the WP_Http class. In particular the http_api_debug action which passes the response to the request or an instance of WP_Error on failure. Combining that with the WC_Logger could be used to implement a basic HTTP debug logger. Something along the lines of:

If one wants to log the details of the HTTP request, one could hook into the http_request_args filter and do something very similar e.g.:

Bonus: In Real Time

Logs are handy for examining the history of request/response pairs, but it’s just a bunch of unwieldy text that’s difficult to make sense of. One might be able to implement some sort of formatter to improve on that. I prefer a different approach, which is to reroute the requests to something built for inspecting HTTP requests.

API monitoring services

A word of caution, the request/response pairs contain a great deal of sensitive information. Routing requests through an API monitoring service results in all of that sensitive information being stored on someone else’s computer. Depending on the legal jurisdiction you operate in, that has a potential to expose a shop owner to heavy consequences. Best to never use this with production/live data.

API monitoring services such as moesif and Runscope and surely others offer some infrastructure that your requests can be run through and request/response pairs are displayed with formatting that makes sense and is much more readable than a jumble of text in a log file.

Generally speaking, these services provide a URL to send requests to. That URL is a specially formatted representation of the original URL that the request is supposed to go to. The monitoring service receives the request, logs the details, and forwards it to the actual URL that it is meant to go to.

Headers and/or query parameters may need to be added depending on the platform used. The pre_http_request filter provides an opportunity to alter a request URL and payload. For an example of how this might be achieved, see: Maybe Route Request Through Moesif on github.

Proxying requests

By using a proxy server that is specifically built to inspect, intercept, and/or alter HTTP requests, we can achieve the same end result of using an API monitoring service. The request itself isn’t altered in any way, but rather the WP_HTTP_Proxy class is used in combination with the pre_http_send_through_proxy filter to pass the request through a proxy server. A basic example:

That’s going to fall apart miserably with HTTPS requests. The sslcertificates parameter in the request args can be used to add the certificate for the upstream proxy. Alternatively, one could set sslverify to false.

Tools

There are a couple of tools that I’ve used that work well for this. The first I’d like to mention is Postman. It is a fantastic tool for inspecting HTTP requests and a great playground for learning. It provides a proxy server and some documentation on how to use it: Capturing HTTP requests This is super handy for local development and testing. Ultimately though, the data is passed through and stored on Postman servers, so again this shouldn’t be done with sensitive data.

The second tool is mitmproxy. For cases where you wish to maintain maximum control over sensitive data, this is the tool to use. It can be deployed on a VPS with a public facing I.P. address for ease of inspecting request/response pairs from a remote WordPress installation. It can also be used locally for local development and it offers an upstream option in case one needs to chain proxies together for whatever reason.