Skip to main content
Yoryantra
Home/Developers

Debugging the Boundary

A surprising number of issues occur at boundaries. For example, converting between text and bytes, URL to request, header to application state, or timestamp with incorrect units. The developer tools within Yoryantra allow you to gain the most value when you have isolated a single boundary and have a specific question to ask.

Parser, Formatter, Builder, or Tester?

A parser will decompose an existing value. A formatter will format a value without changing its meaning. A builder will create a value through an explicit process. A tester will apply a specific rule or behaviour.

These are not interchangeable. If we format a request this does not prove that a server will accept it. Parsing a URL does not prove we can reach the destination. Testing a regular expression tells us how JavaScript will match, but does not tell us if the regular expression represents the business rule we intended.

A useful debugging order

  1. 1. Confirm the raw input you actually have.
  2. 2. Parse or normalize only what is necessary.
  3. 3. Compare the result with the protocol or API contract.
  4. 4. Reproduce the behavior in the real client, server, or browser.

Workflow Types to Consider Splitting

These workflows deliberately combine related tools to help with debugging.

Debugging requests and responses

Build or parse HTTP requests, compare headers, debug API errors and switch between cURL and Fetch without assuming you have done any local processing.

Text, patterns, URLs

Use syntax-sensitive tools to test and parse text where the meaning is determined by delimiters, escaping, regex flags, duplicated query keys and URL resolution rules.

Time, IDs, and small protocol values

Convert time values with explicit units, examine the structure of UUIDs and generate IDs without making any guarantees at an application level.

Local Inspection

A variety of browser tools exist to help you understand requests. You can generate a cURL command from request text, compare two headers, or determine what a given HTTP method does without needing to make a request to the server. This provides deterministic input which is easy to inspect.

There are many more factors to consider when making your request live. DNS lookups, TLS, proxies, redirects, auth state, CORS, caching, service workers, server logic and timing all need to be considered. Tools such as Yoryantra's Redirect Checker will use the response information you provide, rather than silently crawling a URL.

If the bug is network dependent then you should capture the actual request and response using your browsers DevTools, cURL or the appropriate client. Use a specific tool to inspect the difficult to read part.

When the Problem Belongs Somewhere Else

Useful primary references

If you're seeing something that depends on the behaviour of the protocol then it's best to refer back to the specification or platform documentation.