If you ask a receptionist where to deliver an envelope, “try the building next door” is a reasonable answer. Handing over your office keys along with it would be an unusually generous interpretation of the instructions.
Web requests face a version of that problem. A server can tell a client that the thing it wants is somewhere else. Following the directions is convenient; deciding what to carry along is where the interesting decisions begin.
NTNT 0.5.4, released today, changes its HTTP client to follow redirects by default. In 0.5.3, following was an explicit choice. The new default comes with a boundary: credentials can stay with a request on the same origin, but a redirect to a different origin strips them.[1][2] I wanted to see that distinction in something smaller than a release note.
Two doors, one computer
I ran the published Linux x64 binary against two disposable HTTP servers on the same machine. Each server recorded what arrived. The requests carried a fake authorization token, a fake cookie, and a custom header called X-Private. Nothing in the envelopes was valuable.
The servers used different ports. That matters because an origin includes the scheme, hostname, and effective port; changing the port is enough to cross the boundary.[4] You don't need a sinister-looking domain name to make this an interesting test.
When the first server redirected the request to another path on its own port, all three headers arrived. When it redirected to the second server, none of them did. Both requests still reached a final 200 response. Following the directions and withholding the credentials were compatible choices.
Then I made the second server send the request back to the first. The headers stayed absent. The round trip did not earn the token back.
That last detail is the one I like. The migration guide says stripping is permanent across an origin change.[2] The observed request matched it: returning to a familiar address didn't restore everything the request had been carrying before it left.
This was a small loopback test with synthetic plaintext headers, not a security audit. I did not test HTTPS, opaque Secret values, or every redirect status. The fixture had a private-address opt-in scoped to its test process; these observations aren't a reason to loosen an application's network policy.
Sometimes the detour is the thing you're measuring
Following by default is useful if your question is “can I get the page?” It changes the answer if your question is “what did this particular address return?” A monitor expecting to inspect the first response could otherwise report on the destination instead. The migration guide specifically calls out first-hop monitoring and security-header checks.[2]
For that job, ask to stop. I passed map { "redirect": "manual" } as the options argument to fetch. It returned 302, and the fixture's request log showed no follow-up request. There is also an "error" mode for refusing redirects; in the same fixture, it returned an error without contacting the next destination.
An error can't unsend the first request
I tried one more case: a POST with a dummy body, followed by a 307 redirect to the other server. NTNT refused to replay the body across origins. The second server received nothing, but the first had already received the POST.
The error message acknowledged both halves: the next request wasn't sent, and an earlier request might have been processed. The documentation makes the same warning explicit.[2] That is more useful than an error that merely says something went wrong and leaves you to guess whether trying again is harmless.
This is only the HTTP corner of a larger release; the full notes also cover durable job claims and system primitives, with separate upgrade requirements.[3] But it is a corner worth noticing. A convenient default needs an escape hatch for inspection, and an honest failure needs to say where it stopped. Refusing the second delivery does not retrieve the first envelope.
Sources
[4] MDN: Origin