WDC-457: Document fetch credential header handling on cross-origin redirects

[dhaynespls]

While we are currently following the fetch spec, I believe it would be helpful to document this behavior.

[dhaynespls]

Context in node-fetch/node-fetch#1449

[kentonv]

Bikeshedding a bit, what do you think of:

Suggested change

- A [`Headers` object](https://developer.mozilla.org/en-US/docs/Web/API/Headers). <Aside type="warning"> Headers explicitly added to `fetch(url)` will always be sent, even in the case that a redirect is followed. Since Workers does not store nor implicitly add credential headers, explicitly defined `Cookie` and `Authorization` headers will be forwarded when a redirect occurs, even in a cross-origin context.</Aside>

- A [`Headers` object](https://developer.mozilla.org/en-US/docs/Web/API/Headers). Note that, compared to browsers, Cloudflare Workers imposes very few restrictions on what headers you are allowed to send. For example, a browser will not allow you to set the `Cookie` header, since the browser is responsible for handling cookies itself. Workers, however, has no special understanding of cookies, and treats the `Cookie` header like any other header. <Aside type="warning">In the event that the response is a redirect, and the redirect mode is set to `follow` (see below), then all headers will be forwarded to the redirect destination, even if the destination is a different hostname or domain. This includes sensitive headers like `Cookie`, `Authorization`, or any application-specific headers. If this is not the behavior you want, you should set redirect mode to `manual` and implement your own redirect policy. Note that redirect mode defaults to `manual` for requests that originated from the Worker's client, so this warning only applies to `fetch()`es made by a Worker that are not proxying the original request.</Aside>

[dhaynespls]

I think that refactor is a good compromise from my original words and more directly addresses the intent of this change (clarification about how explicitly adding headers to our fetch() implementation works compared to browsers).

You do say "very few restrictions" -> I'm assuming this is referring to the IP headers?

it did look a bit busy like before so I moved it into a note component:

[kentonv]

I wasn't referring to the IP headers, no. I was referring to the list of headers that browsers don't normally allow to be set using fetch(), like Cookie, User-Agent, Date, ...

I'm OK with either of those two screenshots.

[ejcx]

LGTM, don't think I'm a codeowner though

[cloudflare-pages]

Deploying with    Cloudflare Pages

Latest commit:	0d312d4
Status:	✅  Deploy successful!
Preview URL:	https://2931bfcc.cloudflare-docs-7ou.pages.dev

View logs