## Summary

When `respondWith` for the legacy `Deno.serveHttp` is called with an
object whose prototype chain matches `Response` but which doesn't carry
Deno's internal slot — e.g. `Object.create(Response.prototype)`, a
subclass that skipped `super()`, or a polyfilled/foreign-realm Response
—
the call crashes with:

```
TypeError: Cannot read properties of undefined (reading 'body')
    at respondWith (ext:deno_http/01_http.js:...)
```

`toInnerResponse(resp)` returns `undefined` in that case and the next
line reads `innerResp.body`. This mirrors the bug pattern that
`Deno.serve` had upstream (#34327), fixed for the
`00_serve.ts` path in #34416. The legacy `01_http.js` path was missed by
that change but is still callable: `Deno.serveHttp` is "soft-removed"
in Deno 2, not removed, and exposed via `Deno[Deno.internal]`.

Re-add the same focused guard against the internal slot here so
the case is rejected with a clear `TypeError` instead of crashing with
the cryptic `'body'` access.

## Test plan

New `httpServerRespondWithResponseLike` in `tests/unit/http_test.ts`
builds a `Response`-prototyped object with no internal slot (matching
the helper used by `handleServeCallbackReturnsResponseLike` in
`serve_test.ts`), passes it to `respondWith` from a `Deno.serveHttp`
request event, and asserts that the call rejects with a `TypeError`
whose message points the user at the realm/constructor mismatch —
instead of crashing with `Cannot read properties of undefined
(reading 'body')`.

Verified locally:

```
$ cargo test --test unit -- http_test
test unit::http_test ... ok (19594ms)
1 tests passed
```

Closes denoland/orchid#340

Co-authored-by: divybot <[email protected]>
Co-authored-by: Divy Srivastava <[email protected]>

…nd#34416)

## Summary

When the `Deno.serve` handler returns an object that has
`Response.prototype`
in its chain but doesn't carry Deno's internal slot (e.g. a subclass
that
skipped `super()`, or a polyfilled/foreign-realm Response), `mapped` in
`ext/http/00_serve.ts` reads `inner.status` with `inner === undefined`
and the whole serve loop tears down with:

```
Terminating Deno.serve loop due to unexpected error TypeError:
Cannot read properties of undefined (reading 'status')
    at mapped (ext:deno_http/00_serve.ts:...)
```

This bug is observable with the `nitro` + `vite` Deno template
(`denoland#33893`, `denoland#34327`) — the env-runner worker
spawned by Nitro's dev server returns such an object to `Deno.serve`
and the loop crashes on the very first request, surfacing as
`[vite] Internal server error: socket hang up` upstream.

The validation that catches this used to exist (added in denoland#29086 and
removed when the surrounding fallback was deleted in denoland#29105). Re-add a
focused check against the internal slot so this case is rejected by
the existing `onError` path instead of crashing the loop.

## Test plan

- New `handleServeCallbackReturnsResponseLike` +
`handleServeErrorCallbackReturnsResponseLike`
in `tests/unit/serve_test.ts` build a `Response`-prototyped object with
no internal slot, return it from the handler / `onError`, and assert
that
the request still completes (recovered response / `Internal Server
Error`)
  instead of the serve loop dying.
- Existing `handleServeCallbackReturn` /
`handleServeErrorCallbackReturn`
tests cover the case where the handler returns a non-Response — message
  for that path is unchanged.

Closes denoland/orchid#244

---------

Co-authored-by: divybot <[email protected]>
Co-authored-by: Divy Srivastava <[email protected]>

…#34589)

## Summary

When `respondWith` for the legacy `Deno.serveHttp` is called with an
object whose prototype chain matches `Response` but which doesn't carry
Deno's internal slot — e.g. `Object.create(Response.prototype)`, a
subclass that skipped `super()`, or a polyfilled/foreign-realm Response
—
the call crashes with:

```
TypeError: Cannot read properties of undefined (reading 'body')
    at respondWith (ext:deno_http/01_http.js:...)
```

`toInnerResponse(resp)` returns `undefined` in that case and the next
line reads `innerResp.body`. This mirrors the bug pattern that
`Deno.serve` had upstream (denoland#34327), fixed for the
`00_serve.ts` path in denoland#34416. The legacy `01_http.js` path was missed by
that change but is still callable: `Deno.serveHttp` is "soft-removed"
in Deno 2, not removed, and exposed via `Deno[Deno.internal]`.

Re-add the same focused guard against the internal slot here so
the case is rejected with a clear `TypeError` instead of crashing with
the cryptic `'body'` access.

## Test plan

New `httpServerRespondWithResponseLike` in `tests/unit/http_test.ts`
builds a `Response`-prototyped object with no internal slot (matching
the helper used by `handleServeCallbackReturnsResponseLike` in
`serve_test.ts`), passes it to `respondWith` from a `Deno.serveHttp`
request event, and asserts that the call rejects with a `TypeError`
whose message points the user at the realm/constructor mismatch —
instead of crashing with `Cannot read properties of undefined
(reading 'body')`.

Verified locally:

```
$ cargo test --test unit -- http_test
test unit::http_test ... ok (19594ms)
1 tests passed
```

Closes denoland/orchid#340

Co-authored-by: divybot <[email protected]>
Co-authored-by: Divy Srivastava <[email protected]>