Skip to content

account for POST bodies when serializing fetches - #1385

Merged
Rich-Harris merged 2 commits into
masterfrom
gh-633
May 9, 2021
Merged

account for POST bodies when serializing fetches#1385
Rich-Harris merged 2 commits into
masterfrom
gh-633

Conversation

@Rich-Harris

Copy link
Copy Markdown
Member

fixes #633. Figured the pragmatic choice is to ignore requests with a non-string body (as in, they don't get serialized; those fetches are repeated in the client) since other kinds are unlikely in load (presumably the main situation where this is useful is with GraphQL, which uses a JSON payload) and it would be undesirable to buffer streams, etc.

Handling other kinds of bodies is a TODO in any case:

const rendered = await respond(
{
host: request.host,
method: opts.method || 'GET',
headers,
path: resolved,
// TODO per https://developer.mozilla.org/en-US/docs/Web/API/Request/Request, this can be a
// Blob, BufferSource, FormData, URLSearchParams, USVString, or ReadableStream object
// @ts-ignore
rawBody: opts.body,
query: new URLSearchParams(search)
},

In fact, I think for now it might be best to throw an error if non-string bodies are sent in fetch in load. Better than silently failing. Though either way it should affect roughly zero people.

Before submitting the PR, please make sure you do the following

  • It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.

Tests

  • Run the tests with pnpm test and lint the project with pnpm lint

Changesets

  • If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

@benmccann

Copy link
Copy Markdown
Member

Additionally supporting JSON doesn't seem like it should be too hard and might be worth it if it helps add GraphQL support. Though presumably those users could just serialize the JSON to a string themselves before calling fetch

@Rich-Harris

Copy link
Copy Markdown
Member Author

JSON is a string. You don't post body: {...}, you post body: JSON.stringify({...})

@Rich-Harris
Rich-Harris merged commit 2562ca0 into master May 9, 2021
@Rich-Harris
Rich-Harris deleted the gh-633 branch May 9, 2021 16:42
Rich-Harris pushed a commit that referenced this pull request Jul 28, 2026
… is not a string or TypedArray (#16501)

A universal load `fetch` with a `URLSearchParams`, `FormData` or `Blob`
body crashes SSR with `TypeError: value must be a string or TypedArray`
when the response would be inlined. #1385 guarded serialization on the
request body being a string, #6565 re-pointed the check at the response
body, and #9801 removed the throw that had been masking the loss. This
restores the guard. The response isn't serialized and the browser
repeats the fetch.

The client lookup gets the same rule. It hashed only the headers when it
couldn't hash the body, so during hydration such a fetch could resolve
with a different same-url request's serialized response instead of being
sent.

Both tests fail on the base branch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Post request via fetch gets overriden/replaced in load()

2 participants