@depup/h3 2.0.1-depup.0

package/dist/docs/2.examples/3.handle-session.md

@@ -0,0 +1,210 @@
+# Sessions
+
+> Remember your users using a session.
+
+A session is a way to remember users using cookies. It is a very common method for authenticating users or saving data about them, such as their language or preferences on the web.
+
+H3 provides many utilities to handle sessions:
+
+- `useSession` initializes a session and returns a wrapper to control it.
+- `getSession` retrieves the current user session, without starting one.
+- `updateSession` updates the data of the current session.
+- `clearSession` clears the current session.
+Most of the time, you will use `useSession` to manipulate the session.
+
+## Initialize a Session
+
+To initialize a session, you need to use `useSession` in an [event handler](/guide/basics/handler):
+
+```js
+import { useSession } from "h3";
+
+app.use(async (event) => {
+  const session = await useSession(event, {
+    password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",
+  });
+
+  // do something...
+});
+```
+
+> [!WARNING]
+> The `password` seals every session cookie, and its **entropy is the real security boundary**. A stolen session cookie carries the salt and integrity digest in plaintext, so a weak or guessable password can be brute-forced offline — increasing PBKDF2 iterations only slows this, it does not fix a low-entropy secret. Always generate the password from a cryptographically secure random source, for example:
+
+> ```sh
+> node -e "console.log(require('node:crypto').randomBytes(32).toString('base64'))"
+> ```
+
+> The examples below use a hardcoded value so they stay readable, but in a real app load a randomly generated secret of at least 32 characters from an environment variable such as `process.env.SESSION_PASSWORD`, and never commit it to source control. A guessable passphrase (even one ≥32 characters) is not safe.
+
+This will initialize a session and return an header `Set-Cookie` with a cookie named `h3` and an encrypted content.
+
+If the request contains a cookie named `h3` or a header named `x-h3-session`, the session will be initialized with the content of the cookie or the header.
+
+> [!NOTE]
+> The header take precedence over the cookie.
+
+## Get Data from a Session
+
+To get data from a session, we will still use `useSession`. Under the hood, it will use `getSession` to get the session.
+
+```js
+import { useSession } from "h3";
+
+app.use(async (event) => {
+  const session = await useSession(event, {
+    password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",
+  });
+
+  return session.data;
+});
+```
+
+Data are stored in the `data` property of the session. If there is no data, it will be an empty object.
+
+## Add Data to a Session
+
+To add data to a session, we will still use `useSession`. Under the hood, it will use `updateSession` to update the session.
+
+```js
+import { useSession } from "h3";
+
+app.use(async (event) => {
+  const session = await useSession(event, {
+    password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",
+  });
+
+  const count = (session.data.count || 0) + 1;
+  await session.update({
+    count: count,
+  });
+
+  return count === 0 ? "Hello world!" : `Hello world! You have visited this page ${count} times.`;
+});
+```
+
+What is happening here?
+
+We try to get a session from the request. If there is no session, a new one will be created. Then, we increment the `count` property of the session and we update the session with the new value. Finally, we return a message with the number of times the user visited the page.
+
+Try to visit the page multiple times and you will see the number of times you visited the page.
+
+> [!NOTE]
+> If you use a CLI tool like `curl` to test this example, you will not see the number of times you visited the page because the CLI tool does not save cookies. You must get the cookie from the response and send it back to the server.
+
+## Clear a Session
+
+To clear a session, we will still use `useSession`. Under the hood, it will use `clearSession` to clear the session.
+
+```js
+import { useSession } from "h3";
+
+app.use("/clear", async (event) => {
+  const session = await useSession(event, {
+    password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",
+  });
+
+  await session.clear();
+
+  return "Session cleared";
+});
+```
+
+H3 will send a header `Set-Cookie` with an empty cookie named `h3` to clear the session.
+
+## Options
+
+When to use `useSession`, you can pass an object with options as the second argument to configure the session:
+
+```js
+import { useSession } from "h3";
+
+app.use(async (event) => {
+  const session = await useSession(event, {
+    name: "my-session",
+    password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",
+    cookie: {
+      httpOnly: true,
+      secure: true,
+      sameSite: "strict",
+    },
+    maxAge: 60 * 60 * 24 * 7, // 7 days
+  });
+
+  return session.data;
+});
+```
+
+Every option is optional except `password`. The `name` option is worth calling out: it sets the cookie used to store the session and defaults to `h3`. H3 also reads the session from a request header derived from `name`, which it normalizes to lowercase as `x-${name.toLowerCase()}-session`, so the default name `h3` produces the `x-h3-session` header seen earlier. A mixed-case `name` like `MyApp` still resolves to a lowercase `x-myapp-session` header, while the cookie keeps the original casing. That default is why the earlier examples set a cookie named `h3`.
+
+> [!NOTE]
+> The session cookie defaults to `secure: true`, `httpOnly: true`, `sameSite: "lax"`, and `path: "/"`. Any of these can be overridden via `cookie`.
+
+> [!NOTE]
+> The `secure: true` option tells the browser to only store and send the cookie over HTTPS. When developing locally over plain HTTP, compliant browsers (notably Safari and iOS, and Chrome on some local domains) silently drop the cookie, so the session will not persist. Set `cookie: { secure: false }` during local development to work around this.
+
+## Expiration
+
+Sessions have two independent expiration controls, and you can use either or both:
+
+- `maxAge` is an **absolute** lifetime, counted from when the session was created. It is reached however active the user is.
+- `idleTimeout` is a **sliding** lifetime, counted from the last request. An active user stays signed in; an idle one is signed out.
+
+```js
+const session = await useSession(event, {
+  password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",
+  idleTimeout: 60 * 30, // signed out after 30 minutes of inactivity...
+  maxAge: 60 * 60 * 24 * 7, // ...and after 7 days regardless
+});
+```
+With `idleTimeout` set, H3 moves the idle window forward by resealing the session cookie with the reseal time stamped into it. `createdAt` is left untouched, which is what lets `maxAge` still act as a hard cap on top. The cookie `Expires` is set to whichever limit runs out first.
+
+If you are coming from `express-session` or `koa-session`, `idleTimeout` is their `rolling` option. The difference is that it carries its own duration instead of reinterpreting `maxAge`, so enabling it does not cost you the absolute limit.
+
+Resealing is the expensive part of a session, so H3 does not do it on every request: it reseals only once more than half the window has been used, and updating the session counts as a reseal. An active user therefore never gets signed out, but the recorded last-seen time can trail the real one by up to half the window:
+
+```js
+// idleTimeout: 60 * 30
+// Sign-out happens 15 to 30 minutes after the last request, never later.
+```
+
+Halve `idleTimeout` if you need the shorter end of that range to be your real limit.
+
+> [!NOTE]
+> Only cookie sessions slide. A session sent through the `x-{name}-session` header cannot be resealed, so it expires `idleTimeout` after its seal was issued.
+
+> [!IMPORTANT]
+> Because the session lives in the cookie, a request that only reads the session writes it back when it slides the window. If such a request overlaps with one that writes the session, whichever response the browser applies last wins, so the write can be lost. Without `idleTimeout` a read-only request sets no cookie and cannot clobber a concurrent write.
+
+> [!NOTE]
+> A request that slides the window pays for an extra seal and puts a `Set-Cookie` header on its response — shared caches and CDNs often refuse to store those. Requests that only read the session inside the throttle window set no cookie at all.
+
+The session cookie is also applied to error responses, so a request that throws still slides the window and still persists a session created during it.
+
+## Use Multiple Sessions
+
+Because each session is stored under its own `name`, you can run several independent sessions on the same request. They live in separate cookies and never overwrite each other, which is useful for keeping unrelated concerns apart, such as a long-lived auth session and a short-lived flash message:
+
+```js
+import { useSession } from "h3";
+
+app.use(async (event) => {
+  const auth = await useSession(event, {
+    name: "auth",
+    password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",
+  });
+
+  const flash = await useSession(event, {
+    name: "flash",
+    password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",
+  });
+
+  await flash.update({ message: "Saved!" });
+
+  // `auth` and `flash` are backed by different cookies, so they stay separate
+  return { user: auth.data.user, flash: flash.data.message };
+});
+```
+
+> [!NOTE]
+> Give each session a distinct `name`. Two sessions that share a name share the same cookie, so the last write wins.

package/dist/docs/2.examples/4.serve-static-assets.md

@@ -0,0 +1,66 @@
+# Static Assets
+
+> Serve static assets such as HTML, images, CSS, JavaScript, etc.
+
+H3 can serve static assets such as HTML, images, CSS, JavaScript, etc.
+
+To serve a static directory, you can use the `serveStatic` utility.
+
+```ts
+import { H3, serveStatic } from "h3";
+
+const app = new H3();
+
+app.use("/public/**", (event) => {
+  return serveStatic(event, {
+    getContents: (id) => {
+      // TODO
+    },
+    getMeta: (id) => {
+      // TODO
+    },
+  });
+});
+```
+
+This does not serve any files yet. You need to implement the `getContents` and `getMeta` methods.
+
+- `getContents` is used to read the contents of a file. It should return a `Promise` that resolves to the contents of the file or `undefined` if the file does not exist.
+- `getMeta` is used to get the metadata of a file. It should return a `Promise` that resolves to the metadata of the file or `undefined` if the file does not exist.
+They are separated to allow H3 to respond to `HEAD` requests without reading the contents of the file and to use the `Last-Modified` header.
+
+## Read files
+
+Now, create a `index.html` file in the `public` directory with a simple message and open your browser to http://localhost:3000. You should see the message.
+
+Then, we can create the `getContents` and `getMeta` methods:
+
+```ts
+import { stat, readFile } from "node:fs/promises";
+import { join } from "node:path";
+import { H3, serve, serveStatic } from "h3";
+
+const app = new H3();
+
+app.use("/public/**", (event) => {
+  return serveStatic(event, {
+    indexNames: ["/index.html"],
+    getContents: (id) => readFile(join("public", id)),
+    getMeta: async (id) => {
+      const stats = await stat(join("public", id)).catch(() => {});
+      if (stats?.isFile()) {
+        return {
+          size: stats.size,
+          mtime: stats.mtimeMs,
+        };
+      }
+    },
+  });
+});
+
+serve(app);
+```
+
+The `getContents` reads the file and returns its contents, pretty simple. The `getMeta` uses `fs.stat` to get the file metadata. If the file does not exist or is not a file, it returns `undefined`. Otherwise, it returns the file size and the last modification time.
+
+The file size and last modification time are used to create an etag to send a `304 Not Modified` response if the file has not been modified since the last request. This is useful to avoid sending the same file multiple times if it has not changed.

package/dist/docs/2.examples/5.stream-response.md

@@ -0,0 +1,76 @@
+# Stream Response
+
+> Stream response to the client.
+
+Using stream responses It allows you to send data to the client as soon as you have it. This is useful for large files or long running responses.
+
+## Create a Stream
+
+To stream a response, you first need to create a stream using the [`ReadableStream`](https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream) API:
+
+```ts
+const stream = new ReadableStream();
+```
+
+For the example, we will create a start function that will send a random number every 100 milliseconds. After 1000 milliseconds, it will close the stream:
+
+```ts
+let interval: NodeJS.Timeout;
+const stream = new ReadableStream({
+  start(controller) {
+    controller.enqueue("<ul>");
+
+    interval = setInterval(() => {
+      controller.enqueue("<li>" + Math.random() + "</li>");
+    }, 100);
+
+    setTimeout(() => {
+      clearInterval(interval);
+      controller.close();
+    }, 1000);
+  },
+  cancel() {
+    clearInterval(interval);
+  },
+});
+```
+
+## Send a Stream
+
+```ts
+import { H3 } from "h3";
+
+export const app = new H3();
+
+app.use((event) => {
+  // Set to response header to tell to the client that we are sending a stream.
+  event.res.headers.set("Content-Type", "text/html");
+  event.res.headers.set("Cache-Control", "no-cache");
+  event.res.headers.set("Transfer-Encoding", "chunked");
+
+  let interval: NodeJS.Timeout;
+  const stream = new ReadableStream({
+    start(controller) {
+      controller.enqueue("<ul>");
+
+      interval = setInterval(() => {
+        controller.enqueue("<li>" + Math.random() + "</li>");
+      }, 100);
+
+      setTimeout(() => {
+        clearInterval(interval);
+        controller.close();
+      }, 1000);
+    },
+    cancel() {
+      clearInterval(interval);
+    },
+  });
+
+  return stream;
+});
+```
+
+Open your browser to http://localhost:3000 and you should see a list of random numbers appearing every 100 milliseconds.
+
+Magic! 🎉

package/dist/docs/2.examples/6.validate-data.md

@@ -0,0 +1,193 @@
+# Validate Data
+
+> Ensure that your data are valid and safe before processing them.
+
+When you receive data on your server, you must validate them. By validate, we mean that the shape of the received data must match the expected shape. It's important because you can't trust the data coming from unknown sources, like a user or an external API.
+
+> [!WARNING]
+> Do not use type generics as a validation. Providing an interface to a utility like `readBody` is not a validation. You must validate the data before using it.
+
+## Utilities for Validation
+
+H3 provide some utilities to help you to handle data validation. You will be able to validate:
+
+- query with `getValidatedQuery`
+- params with `getValidatedRouterParams`.
+- body with `readValidatedBody`
+H3 doesn't provide any validation library but it does support schemas coming from a **Standard-Schema** compatible one, like: [Zod](https://zod.dev), [Valibot](https://valibot.dev), [ArkType](https://arktype.io/), etc... (for all compatible libraries please check [their official repository](https://github.com/standard-schema/standard-schema)). If you want to use a validation library that is not compatible with Standard-Schema, you can still use it, but you will have to use parsing functions provided by the library itself (refer to the [Safe Parsing](#safe-parsing) section below).
+
+> [!WARNING]
+> H3 is runtime agnostic. This means that you can use it in [any runtime](/guide). But some validation libraries are not compatible with all runtimes.
+
+Let's see how to validate data with [Zod](https://zod.dev) and [Valibot](https://valibot.dev).
+
+### Validate Params
+
+You can use `getValidatedRouterParams` to validate params and get the result, as a replacement of `getRouterParams`:
+
+```js
+import { getValidatedRouterParams } from "h3";
+import * as z from "zod";
+import * as v from "valibot";
+
+// Example with Zod
+const contentSchema = z.object({
+  topic: z.string().min(1),
+  uuid: z.string().uuid(),
+});
+// Example with Valibot
+const contentSchema = v.object({
+  topic: v.pipe(v.string(), v.nonEmpty()),
+  uuid: v.pipe(v.string(), v.uuid()),
+});
+
+app.all(
+  // You must use a router to use params
+  "/content/:topic/:uuid",
+  async (event) => {
+    const params = await getValidatedRouterParams(event, contentSchema);
+    return `You are looking for content with topic "${params.topic}" and uuid "${params.uuid}".`;
+  },
+);
+```
+
+If you send a valid request like `/content/posts/123e4567-e89b-12d3-a456-426614174000` to this event handler, you will get a response like this:
+
+```txt
+You are looking for content with topic "posts" and uuid "123e4567-e89b-12d3-a456-426614174000".
+```
+
+If you send an invalid request and the validation fails, H3 will throw a `400 Validation Error` error. In the data of the error, you will find the validation errors you can use on your client to display a nice error message to your user.
+
+### Validate Query
+
+You can use `getValidatedQuery` to validate query and get the result, as a replacement of `getQuery`:
+
+```js
+import { getValidatedQuery } from "h3";
+import * as z from "zod";
+import * as v from "valibot";
+
+// Example with Zod
+const stringToNumber = z.string().regex(/^\d+$/, "Must be a number string").transform(Number);
+const paginationSchema = z.object({
+  page: stringToNumber.optional().default(1),
+  size: stringToNumber.optional().default(10),
+});
+
+// Example with Valibot
+const stringToNumber = v.pipe(
+  v.string(),
+  v.regex(/^\d+$/, "Must be a number string"),
+  v.transform(Number),
+);
+const paginationSchema = v.object({
+  page: v.optional(stringToNumber, 1),
+  size: v.optional(stringToNumber, 10),
+});
+
+app.use(async (event) => {
+  const query = await getValidatedQuery(event, paginationSchema);
+  return `You are on page ${query.page} with ${query.size} items per page.`;
+});
+```
+
+As you may have noticed, compared to the `getValidatedRouterParams` example, we can leverage validation libraries to transform the incoming data. In this case, we transform the string representation of a number into a real number, which is useful for things like content pagination.
+
+If you send a valid request like `/?page=2&size=20` to this event handler, you will get a response like this:
+
+```txt
+You are on page 2 with 20 items per page.
+```
+
+If you send an invalid request and the validation fails, H3 will throw a `400 Validation Error` error. In the data of the error, you will find the validation errors you can use on your client to display a nice error message to your user.
+
+### Validate Body
+
+You can use `readValidatedBody` to validate body and get the result, as a replacement of `readBody`:
+
+```js
+import { readValidatedBody } from "h3";
+import { z } from "zod";
+import * as v from "valibot";
+
+// Example with Zod
+const userSchema = z.object({
+  name: z.string().min(3).max(20),
+  age: z.number({ coerce: true }).positive().int(),
+});
+
+// Example with Valibot
+const userSchema = v.object({
+  name: v.pipe(v.string(), v.minLength(3), v.maxLength(20)),
+  age: v.pipe(v.number(), v.integer(), v.minValue(0)),
+});
+
+app.use(async (event) => {
+  const body = await readValidatedBody(event, userSchema);
+  return `Hello ${body.name}! You are ${body.age} years old.`;
+});
+```
+
+If you send a valid POST request with a JSON body like this:
+
+```json
+{
+  "name": "John",
+  "age": 42
+}
+```
+
+You will get a response like this:
+
+```txt
+Hello John! You are 42 years old.
+```
+
+If you send an invalid request and the validation fails, H3 will throw a `400 Validation Error` error. In the data of the error, you will find the validation errors you can use on your client to display a nice error message to your user.
+
+## Safe Parsing
+
+By default if a schema is directly provided as e second argument for each validation utility (`getValidatedRouterParams`, `getValidatedQuery`, and `readValidatedBody`) it will throw a `400 Validation Error` error if the validation fails, but in some cases you may want to handle the validation errors yourself. For this you should provide the actual safe validation function as the second argument, depending on the validation library you are using.
+
+Going back to the first example with `getValidatedRouterParams`, for Zod it would look like this:
+
+```ts
+import { getValidatedRouterParams } from "h3";
+import { z } from "zod/v4";
+
+const contentSchema = z.object({
+  topic: z.string().min(1),
+  uuid: z.string().uuid(),
+});
+
+app.all("/content/:topic/:uuid", async (event) => {
+  const params = await getValidatedRouterParams(event, contentSchema.safeParse);
+  if (!params.success) {
+    // Handle validation errors
+    return `Validation failed:\n${z.prettifyError(params.error)}`;
+  }
+  return `You are looking for content with topic "${params.data.topic}" and uuid "${params.data.uuid}".`;
+});
+```
+
+And for Valibot, it would look like this:
+
+```ts
+import { getValidatedRouterParams } from "h3";
+import * as v from "valibot";
+
+const contentSchema = v.object({
+  topic: v.pipe(v.string(), v.nonEmpty()),
+  uuid: v.pipe(v.string(), v.uuid()),
+});
+
+app.all("/content/:topic/:uuid", async (event) => {
+  const params = await getValidatedRouterParams(event, v.safeParser(contentSchema));
+  if (!params.success) {
+    // Handle validation errors
+    return `Validation failed:\n${v.summarize(params.issues)}`;
+  }
+  return `You are looking for content with topic "${params.output.topic}" and uuid "${params.output.uuid}".`;
+});
+```