Reserve app ports and validate fixed app-port inputs#151
Reserve app ports and validate fixed app-port inputs#151lucinadin wants to merge 1 commit intovercel-labs:mainfrom
Conversation
|
@lucinadin is attempting to deploy a commit to the Vercel Labs Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dedb2caa15
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (isReservedAppPort(port)) { | ||
| console.error(chalk.red(`Error: Invalid app port "${value}". This app port is reserved.`)); | ||
| console.error( | ||
| chalk.blue("Choose a different port, or omit --app-port for automatic assignment.") | ||
| ); | ||
| process.exit(1); |
There was a problem hiding this comment.
Don't ban reserved fixed ports that are only backend ports
runApp() still publishes only the proxy URL to the browser, and createProxyServer() forwards requests to 127.0.0.1:route.port internally (packages/portless/src/proxy.ts, http.request in handleRequest). That means the browser never connects to the app's listen port directly, so many fixed-port setups that used to work behind portless (for example services pinned to 6000 or 6667 to match local tooling) now fail for no protocol reason, while equivalent portless alias <name> <port> routes are still accepted in handleAlias(). Auto-assignment should skip bad ports, but rejecting every fixed bad port here is an unnecessary regression.
Useful? React with 👍 / 👎.
| if (isReservedAppPort(port)) { | ||
| console.error( | ||
| chalk.red(`Error: Invalid PORTLESS_APP_PORT="${envVal}". This app port is reserved.`) | ||
| ); | ||
| console.error( | ||
| chalk.blue("Set a different port, or unset PORTLESS_APP_PORT for auto-assignment.") | ||
| ); | ||
| process.exit(1); |
There was a problem hiding this comment.
Skip app-port validation in PORTLESS=0 bypass mode
main() still routes the PORTLESS=0 escape hatch through parseRunArgs() / parseAppArgs() before it spawns the child directly (packages/portless/src/cli.ts:1493-1504), and in that path the parsed app port is never used. With this check in place, PORTLESS=0 PORTLESS_APP_PORT=4045 portless run ... or PORTLESS=0 portless run --app-port 4045 ... now exits 1 instead of bypassing portless, which breaks the documented disable-portless workflow for shells or scripts that leave those settings around.
Useful? React with 👍 / 👎.
Summary
I ran into this Next.js reserved-port issue:
https://nextjs.org/docs/messages/reserved-port
From there, I used the Fetch bad-port list it links to:
https://fetch.spec.whatwg.org/#port-blocking
This PR makes
portlesstreat those as reserved app ports, so we stop assigning or accepting ports that will fail at runtime.What I changed
--app-portandPORTLESS_APP_PORT) to reject reserved app ports early.skills/portless/SKILL.mdto document the new behavior.Result
portlessnow consistently avoids reserved app ports across both automatic and fixed port flows.AI disclaimer
I used OpenAI GPT-5.3 Codex (high reasoning mode) to help with implementation and test updates.