fix: #4264

I am accessing the Demo app from Tokyo but the response is not good. I considered using indexedDB or Session Storage but did not adopt them because it is important that this process be performed on the back end. And the process should not be complex to avoid making noise, so I finally opted for a simple in-memory object. Any opinions for a better demo app?

Please don't delete this checklist! 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 and pnpm check

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. All changesets should be patch until SvelteKit 1.0

Fixes #3503 Fixes #696 Reverts #3631 Reverts #835

Okay this is the last one of my SvelteKit wishlist items. Not sure what you'll think but it certainly makes sense to me.

This does two things, each in its own commit.

1. Exposes event to the load() function
2. Reverts and deletes all the logic related to passing headers and cookies to the upstream service calls.

#3631 was clearly a mistake. If we have a network call graph that looks something like this:

It doesn't make any sense for the Node service to pretend to be a browser. Some of the reasons:

• You're lying about the user agent. If you passed one at all it should be, perhaps, node/sveltekit or something
• You're passing headers unidirectionally, sending them out but but not sending the response headers back to the browser, because of course that wouldn't make any sense. The calls are many to one so what should you do, merge them?
• The type is different (HTML vs most likely JSON), so the accept header could be wrong
• Some of the headers are nonsensical for service-to-service calls, like referer which is a browser concern

There just seems to be some confusion and it seems like people are considering calls A-C in the graph to be the Z call proxied onward. When in fact those calls are unrelated to call Z, except that call Z is the reason calls A-C are being made.

But then even with all the complexity, we still can't pass along the most important information: the auth cookies. To get the full details of the incoming request you have to use an endpoint (or a hook). Endpoints should be a feature you can use if you want but shouldn't be mandatory.

In a more ops-driven, "close to the metal" kind of enterprise setup, our frontend services live among a constellation of other services, both in front as reverse proxies, and behind as upstream services. In this world things like SSL termination and endpoints are simply not wanted or needed. In this world if we want to avoid the moving target of CORS and serve our data on the same domain as our HTML, we simply put a reverse proxy in front and split traffic.

What this change does is restores control. If you want to call your backend services and spoof like you're a browser, you can do so! Copy all your headers over. If you want to forward a backend service's "set-cookie" directive to the browser, go ahead. But if you do nothing the calls to the backends get no headers, just as if you made a curl call, which seems like a pretty reasonable thing to do by default.

Here's some examples:

export default async function load({ event, params, fetch }) {
  let response = await fetch('https://a.backend.com/data/' + event.id, {
    headers: {
      // Use end user credentials
      // You could parse the cookie string and slice out a specific auth cookie, or
      // or just pass the whole darn thing.
      cookie: event?.request.headers.get('cookie'), // only relevant server-side
      credentials: 'include', // only relevant client-side
    },
  });
  ...
}

If your backend sets a cookie and you want to set the same cookie in the browser, there's no way to do that explicitly, and I stripped out the automatic logic for that because, hey, making service calls shouldn't have side effects. You get the data, you do what you want with the data, end of story. So I extended some interfaces with a set_cookies string array.

export default async function load({ event, params, fetch }) {
  let response = await fetch('https://a.backend.com/data/' + event.id, {
    headers: {
      cookie: event?.request.headers.get('cookie'), // only relevant server-side
      credentials: 'include', // only relevant client-side
    },
  });
  let data = await response.json();
  let set_cookie = response.headers.get('set-cookie');
  return {
    props: {
      widgets: data.widgets
    },
    set_cookies: set_cookie && [set_cookie],
}

More rationale: Even in the demo TODO app, you need access to the user's cookies to make the backend call. I know that backend is slated for removal in #4264 but as long as it remains it does prove a point. In my repro case for #4902 I have code like this:

johnnysprinkles/sveltekit_after_navigate_bug@53dd01a (comment)

where I have to put the userid in session because there's no way to read it from the request in load(). If you don't want to put it in session and you don't want to use an endpoint, you're currently out of luck.

Anyway, I hope this might at least provoke some discussion. I know this goes against a SvelteKit value of abstracting away the differences between client and server, but that abstraction is kind of a fiction anyway.

Also, I have no idea how much this would break. Shadow endpoints? Various adapters?

Please don't delete this checklist! 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 and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

Playable here: https://kit-git-sverdle-svelte.vercel.app/sverdle

• Closes #1564
• Closes #4266
• Closes #4264

The /todos app in the default template is a nice idea, but it's a bit misleading. People understandably imagine that the back end runs locally and then are surprised by the latency.

This PR replaces it with a Wordle clone that keeps all the game logic and data on the server, and persists user state using cookies.

It's not 100% finished — there's a subtle bug with the keyboard showing some letters as wrong instead of right-letter-wrong-place, and it needs some instructions and probably some style tweaks. I'd also love to get some help on the a11y front (cc @geoffrich!)

Please don't delete this checklist! 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 and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0