# Exercise 2: Trace a Redirect Through the Pipeline

A user is logged into `https://app.example.com` (has a session cookie scoped to that host). Their page contains:

```js
fetch("https://app.example.com/legacy-export", { credentials: "same-origin" })
  .then(res => res.json());
```

The server at `https://app.example.com/legacy-export` responds with:

```
HTTP/1.1 307 Temporary Redirect
Location: https://export-worker.example.com/generate
```

`export-worker.example.com` does **not** send any `Access-Control-Allow-Origin` header in its response.

Walk through the pipeline step by step and answer:

```
TODO: answer each question with your reasoning, not just a final word.

1. Does the browser automatically follow the 307 redirect for a fetch()
   call using the default redirect mode? What does fetch's default
   `redirect` option value do here?

2. When the browser builds the SECOND request (to export-worker.example.com),
   is that request same-origin or cross-origin relative to app.example.com?

3. Will the browser attach app.example.com's session cookie to the
   SECOND request (to export-worker.example.com)? Why or why not?

4. Does export-worker.example.com's server actually receive and process
   the second request, regardless of any CORS headers?

5. Will fetch()'s .then(res => res.json()) callback ever run successfully
   in the calling page's JS? Justify using the SOP/CORS gate concept.
```

---

## Self-Check

1. Yes — `fetch`'s default `redirect` option is `"follow"`, so the browser transparently follows the 307 without the calling JS seeing an intermediate response; the `fetch()` promise resolves (or rejects) based on the *final* hop.
2. **Cross-origin.** `export-worker.example.com` is a different host than `app.example.com`, even though both are subdomains of `example.com` — origin comparison uses the full host, not the registrable/eTLD+1 domain (this distinction is explored fully in the Hostname vs Domain topic).
3. **No** — `app.example.com`'s session cookie is scoped to that host (`Domain=app.example.com` or unset, meaning host-only). The second request's destination is `export-worker.example.com`, a different host, so the browser's cookie jar has no matching cookie to attach for that host, independent of any redirect mechanics. (If `export-worker.example.com` has its own cookies, *those* would be attached instead, following the same "cookies match the destination" rule from the theory file.)
4. **Yes** — the request is sent over the network and the server processes it and returns a response, regardless of what CORS headers it does or doesn't include. CORS is enforced by the requesting browser on the *response*, not by preventing the request from reaching the server.
5. **No** — because the final response came from a cross-origin server (`export-worker.example.com`) with no `Access-Control-Allow-Origin` header, the browser's SOP/CORS gate blocks the calling script from reading the response body. `res.json()` will typically throw or the `fetch()` call itself rejects with a `TypeError: Failed to fetch`, even though the server-side work (whatever `generate` does) already happened.