# Exercise 1: Classify the Origin Pairs

For each pair of URLs below, decide whether they are **same-origin** or **cross-origin**, and state which part of the `(scheme, host, port)` triple differs (if any).

```
TODO: fill in your answer for each pair as same-origin / cross-origin,
and name the differing component(s) for any cross-origin pair.

1. https://shop.example.com/cart          vs  https://shop.example.com/checkout
   → ?

2. https://shop.example.com/cart          vs  http://shop.example.com/cart
   → ?

3. https://shop.example.com/cart          vs  https://api.shop.example.com/cart
   → ?

4. https://shop.example.com/cart          vs  https://shop.example.com:8443/cart
   → ?

5. https://shop.example.com                vs  https://shop.example.com:443
   → ?

6. https://shop.example.com/cart          vs  https://shop.example.com./cart   (trailing dot)
   → ?
```

For each cross-origin pair, also answer: if page 1 tried to `fetch()` page 2's URL and read the JSON response, would the Same-Origin Policy allow that by default (before any CORS headers are considered)?

---

## Self-Check

Compare your answers against these before moving on:

1. **Same-origin.** Only the path differs; scheme, host, and port are identical. Path is not part of the origin triple.
2. **Cross-origin — scheme differs** (`https` vs `http`).
3. **Cross-origin — host differs.** `api.shop.example.com` and `shop.example.com` are different hosts; subdomains are never treated as the same origin automatically.
4. **Cross-origin — port differs** (`443` implicit vs `8443` explicit).
5. **Same-origin.** `https://` implies port 443, so writing `:443` explicitly changes nothing.
6. **Cross-origin in strict terms, though browsers normalize the trailing dot in practice for DNS purposes; conceptually still worth noting hostnames are compared as written by origin-comparison algorithms**, which is why trailing-dot FQDNs occasionally cause subtle mismatches in strict origin-checking code (not in the browser's own SOP implementation, which normalizes this, but in application-level origin allowlists that do naive string comparison — a real source of bugs).
7. For every cross-origin pair (2, 3, 4, 6 in the strict-comparison sense): **no**, SOP blocks the calling page's JS from reading the response by default. The request itself is still sent by the browser (and the server still processes it) — only the ability to *read* the result is denied unless the target server opts in with CORS headers (see the CORS topic).