calling python3 -m http.server -port <port> results in ERR_INVALID_HTTP_RESPONSE

[GARBAGELINUXGRAPHIC]

Bug report

Bug description:

I know the correct command is python3 -m http.server <port>, however:

Typing python3 -m http.server -port <port> results in ERR_INVALID_HTTP_RESPONSE in chrome, and seemingly working terminal response:

python -m http.server -port 3000
Serving HTTP on :: port 3000 (https://[::]:3000/) ...
::1 - - [06/Apr/2026 22:27:38] "GET / HTTP/1.1" 200 -
::1 - - [06/Apr/2026 22:27:39] "GET / HTTP/1.1" 200 -

As you can see here, it says it serve HTTP on port 3000, and is handling GET "successfully", while in reality it results in ERR_INVALID_HTTP_RESPONSE in the browser.

Other commands like python -m http.server --port 3000
results in an error:

usage: server.py [-h] [--cgi] [-b ADDRESS] [-d DIRECTORY] [-p VERSION] [port]
server.py: error: unrecognized arguments: --port

I think this is what executing the command above(using -port) should the program behave.

Also: executing python -m http.server -p 3000
results in:

Serving HTTP on :: port 8000 (https://[::]:8000/) ...

it serves on default port, as if nothing happened. This is also not that good, it should work/throw an error, but is not as frustrating as using -port, which magically dont throws an error and break.

The problem is this "seemingly working but in fact it's not" behaviour. It could be more user friendly.

CPython versions tested on:

3.12

Operating systems tested on:

Linux

[gvanrossum]

I looked into this.

Argparser (used by http.server) parses -port as -p ort which equivalent to --protocol ort. That sets the protocol (default HTTP/1.0) to the string ort and that confuses clients.

I don't think there's much we can do about thus unless you want to write a validator for HTTP protocol values. But even that might confuse currently working code -- someone might write a custom client that requires a specific magic string but otherwise just talks HTTP.