How can you inspect an HTTP exchange without exposing credentials?
Quick answer
Before sharing an HTTP exchange, make a separate copy and replace credential values and private information with clear placeholders. In particular, omit or replace values in Authorization and Proxy-Authorization headers: they carry credentials. [S1] Keep only the request and response details needed to explain the issue, and check the entire example—including URLs, headers, and body—for sensitive values before sharing. A generic example can show a 401 challenge without a real credential. [S2]
The question, the details, the next step.
I need to show a request and response to get help, but the exchange came from a real session. What should I do first?
Treat the real exchange as material to inspect, not as something to copy directly into a message or issue report. Create a separate working copy, then remove or replace credentials and private data before sharing. MDN identifies Authorization and Proxy-Authorization as headers that carry credentials for authenticating with a server or proxy, so do not include their real values in the shared example. [S1]
Also review the rest of the exchange, not just those two headers. Look for personal or account details in the URL, other headers, and request or response body. Preserve the parts needed to explain what happened, such as the request method, a suitably generic path, and the relevant response status. If a detail is not needed to understand the issue, leave it out.
Can you show what a safer example might look like if the problem is a 401 response?
Yes. A 401 example can be discussed without copying a real authorization credential. MDN illustrates a protected-resource request and a server response containing a WWW-Authenticate challenge. [S2] For example, you could write:
GET /[protected-resource] HTTP/1.1
Host: [example-host]
Authorization: [redacted]
HTTP/1.1 401 Unauthorized
WWW-Authenticate: [challenge details, if relevant]
This is a documentation example, not a claim that these exact lines match your exchange. Replace hostnames, paths, tokens, and any other identifying values with placeholders. Keep challenge details only if they help explain the question; the example need not reproduce every header or body field.
How do I know what details to keep so the example remains useful for troubleshooting?
Keep the smallest set of details that lets someone understand the sequence and the symptom. You might retain the method, a generalized endpoint, the status code, and a relevant response header or short error message. Label changed values consistently—for example, use [account-id] wherever the same private value appears—so the example remains readable without revealing the original.
Before sharing, read the prepared copy from top to bottom. Check query parameters, cookies, custom headers, and body fields as well as the obvious authentication header. Remove unrelated exchanges and any content that does not help explain the issue. These are practical editing suggestions, not a guarantee that a particular redaction method or logging tool will catch every sensitive value; the cited HTTP pages explain authentication and a 401 challenge, not a general log-sanitization procedure. [S1] [S2]
Can you give me a short reusable template for the report?
Use this as a starting point, filling only fields relevant to the problem:
What I expected: [brief description]
What happened: [brief description]
Request: [method] [generalized path]
Relevant request headers: [header name]: [redacted or safe placeholder]
Response: [status code]
Relevant response details: [selected header or short, reviewed message]
What I removed or generalized: [credentials, identifiers, private fields]
For a 401 question, a generic protected-resource request and challenge can illustrate the exchange without supplying a real credential. [S2] Review the completed template once more before sharing, and omit any field you cannot safely or appropriately disclose.
A practical checklist
Work from a separate copy; do not paste the unedited exchange into the report.
Replace or omit real values in
AuthorizationandProxy-Authorizationheaders. [S1]Review URLs, query parameters, cookies, other headers, and message bodies for private values.
Keep only the method, generalized path, status, and response details needed to explain the issue.
Read the final example from beginning to end and replace identifying values with clear placeholders.
A few more useful answers
Should I include a real authorization token if it helps explain the failure?
No. Replace the value with [redacted] or omit the header. The header carries authentication credentials, so a generic placeholder is more appropriate for a shared example. [S1]
Can I explain a 401 response without sharing a credential?
Yes. Use a generic protected-resource request and, if relevant, describe the WWW-Authenticate challenge in the response. MDN’s example illustrates this without requiring a real credential. [S2]
Does this template guarantee that every sensitive value has been removed?
No. It is a review aid, not a guarantee or a prescribed sanitization method. Inspect the full exchange and follow the sharing rules that apply to your situation.
Sources
References used for this guide.
- [S1] HTTP authentication — HTTP | MDN developer.mozilla.org · Checked
- [S2] 401 Unauthorized — HTTP | MDN developer.mozilla.org · Checked