Symptom
```
git -c http.extraHeader="Authorization: Bearer $TOKEN"
push http://localhost:5444/public/apps/chat HEAD:gh-pages
→ error: RPC failed; HTTP 413
→ send-pack: unexpected disconnect while reading sideband packet
→ fatal: the remote end hung up unexpectedly
```
Hit this trying to install solid-chat/app on a jspod — the pack is ~30 MiB (3 years of history; tracked working tree is only ~444 KB), and JSS rejects it.
Cause
`src/server.js:187` hard-codes Fastify's `bodyLimit` to 10 MB:
```js
const fastifyOptions = {
…
bodyLimit: 10 * 1024 * 1024, // 10MB
…
};
```
This caps every request body across the server. Reasonable for normal PUT/POST, but git pushes can be much larger — especially first-push of an established repo, or merges with binary assets.
The git handler runs as a `preHandler` hook on wildcard routes (`fastify.addHook('preHandler', …)` at server.js:500), so Fastify's body-size check has already fired before any git-specific code runs. A route-level `bodyLimit` override isn't reachable here.
Proposed fix
Make `bodyLimit` configurable:
- `createServer({ bodyLimit })` option, default `10 * 1024 * 1024` (no behavior change).
- CLI flag: `--body-limit <bytes|kb|mb|gb>` (or `--max-upload-size`), parsed to bytes.
- Document the trade-off in `--help`: higher = bigger pushes accepted, lower = more memory-DoS resistant.
```js
bodyLimit: options.bodyLimit ?? (10 * 1024 * 1024),
```
Wrappers like jspod can then default to a more generous limit (e.g. 100 MB) for the personal-pod use case where the operator is the user.
Scope
~5 LoC in `src/server.js` + CLI arg parsing in `bin/jss.js` + a help-line update. No new dependencies. Test: existing tests pass with default; one new test pushing a >10 MB pack with raised limit.
Optional follow-up
If we want git pushes to be the only thing that can exceed the global cap, we could pre-parse the URL in a custom `contentTypeParser` and apply a different limit for `application/x-git-receive-pack-request`. More surgical, but more code. Open to either path.
Symptom
```
git -c http.extraHeader="Authorization: Bearer $TOKEN"
push http://localhost:5444/public/apps/chat HEAD:gh-pages
→ error: RPC failed; HTTP 413
→ send-pack: unexpected disconnect while reading sideband packet
→ fatal: the remote end hung up unexpectedly
```
Hit this trying to install solid-chat/app on a jspod — the pack is ~30 MiB (3 years of history; tracked working tree is only ~444 KB), and JSS rejects it.
Cause
`src/server.js:187` hard-codes Fastify's `bodyLimit` to 10 MB:
```js
const fastifyOptions = {
…
bodyLimit: 10 * 1024 * 1024, // 10MB
…
};
```
This caps every request body across the server. Reasonable for normal PUT/POST, but git pushes can be much larger — especially first-push of an established repo, or merges with binary assets.
The git handler runs as a `preHandler` hook on wildcard routes (`fastify.addHook('preHandler', …)` at server.js:500), so Fastify's body-size check has already fired before any git-specific code runs. A route-level `bodyLimit` override isn't reachable here.
Proposed fix
Make `bodyLimit` configurable:
```js
bodyLimit: options.bodyLimit ?? (10 * 1024 * 1024),
```
Wrappers like jspod can then default to a more generous limit (e.g. 100 MB) for the personal-pod use case where the operator is the user.
Scope
~5 LoC in `src/server.js` + CLI arg parsing in `bin/jss.js` + a help-line update. No new dependencies. Test: existing tests pass with default; one new test pushing a >10 MB pack with raised limit.
Optional follow-up
If we want git pushes to be the only thing that can exceed the global cap, we could pre-parse the URL in a custom `contentTypeParser` and apply a different limit for `application/x-git-receive-pack-request`. More surgical, but more code. Open to either path.