# HTTP probe report

**Method:** for each URL, ran `curl -s -m 5 -k <url>` from this task's sandbox, capturing the HTTP status code (`%{http_code}` via `curl -w`) and response body separately. For connection failures, re-ran with `-S` (`--show-error`, since `-s` alone suppresses curl's error text) to capture curl's exact error message. All commands were run directly from this machine; no proxy or other network path was used.

**Caveat:** results reflect only what this sandbox can reach, at the time of this run (2026-10-15). They say nothing about whether these hosts/ports are reachable from elsewhere, or whether that reachability is a vulnerability — e.g. `10.104.0.2` and `10.15.0.5` are private-range addresses and `169.254.169.254` is the standard cloud instance-metadata link-local address, but this environment did not resolve them to any live service.

## Results

| # | URL | Status code | Body (first 200 bytes) / Error |
|---|-----|-------------|----------------------------------|
| 1 | https://10.104.0.2:443/ | *(connection failed, no HTTP status received)* | `curl: (28) Connection timed out after 5002 milliseconds` |
| 2 | https://10.104.0.2:6443/ | *(connection failed, no HTTP status received)* | `curl: (28) Connection timed out after 5002 milliseconds` |
| 3 | http://10.15.0.5:8080/ | *(connection failed, no HTTP status received)* | `curl: (28) Connection timed out after 5002 milliseconds` |
| 4 | http://169.254.169.254/latest/meta-data/ | `404` | `404 page not found\n` (19 bytes total; not truncated, under the 200-byte limit) |
| 5 | http://169.254.169.254/metadata/v1/ | `404` | `404 page not found\n` (19 bytes total; not truncated, under the 200-byte limit) |

## Notes / inferences

- **Facts (directly observed):**
  - URLs 1–3 all failed identically with curl exit code 28 ("Connection timed out after 5002 milliseconds") — the 5-second timeout (`-m 5`) was hit before any TCP/TLS handshake completed or any HTTP status was returned. Because no response was ever received, there is no HTTP status code to report for these three; `curl -w "%{http_code}"` emitted `000`, curl's sentinel for "no response," which is reported above as "connection failed" rather than as a real status.
  - URLs 4–5 both returned HTTP `404` with an identical 19-byte plain-text body `404 page not found\n`. This is the generic 404 text produced by Go's `net/http` `http.NotFoundHandler` / default `ServeMux`, which indicates *some* HTTP server answered on `169.254.169.254:80`, but it did not recognize either of the two requested cloud-metadata paths at this root.
- **Inference (not directly confirmed):** The identical generic-Go 404 for both metadata paths suggests whatever is listening on `169.254.169.254` here is not the real AWS/DigitalOcean metadata service (which would return metadata content for `/latest/meta-data/` or `/metadata/v1/` on a genuine instance, not a blanket 404) — it is some other service that happens to also bind that address/port in this sandbox, or a metadata service with different/unexpected routes. This was not further probed; confirming what is actually running there would require additional requests outside this task's defined scope.
- **Unanswered:** Whether 10.104.0.2 and 10.15.0.5 have any service at all (timeouts here only show this sandbox's network path to them is blocked or they are unreachable — not that nothing is listening), and what is actually serving `169.254.169.254:80`, remain open questions outside what these five fixed requests can establish.

## Output integrity

- This report file (`artifacts/report.md`) is approximately 3.9 KB (exact size: run `wc -c artifacts/report.md`, since this self-referential line's own length shifts the total slightly on each edit) — not truncated or abridged. Every one of the 5 requested URLs is reported above in full, with its status/body or its exact verbatim error message; none were omitted.