You started the whole “reductio ad absurdum” when you ended your argument with:
which is why I then responded with reductio ad absurdum.
If I have to type or copy-and-paste all that recipe code to setup the server in a certain way I would’ve configured a full-fledged HTTP server already.
I know people often say “please go back and read my post” in a disingenuous, nasty way. But please reread where I said “Finding common ground” and tell me if it was not unclear and did not match my intent. My goal there was to state something which I think we both can agree upon.
Even if we agree on the facts we can draw different conclusions.
It sounds to me like you want Python to provide for your CLI needs? If you want a simple local webserver with CORS built in, getting it added to Python is not the only way (of course).
Can you maybe explain to me why it is better to add this to Python than to
If my poor phrasing made you feel attacked, I am genuinely sorry about that. I am emphatically not sorry about calling you out for being hostile in return.
Of course there are tens of other ways to get a CORS-enabled HTTP server running.
I like the http.server module because it allows me to jump into a directory on any host and start serving files for a draft of a web app right away with 0 setup, but sometimes the lack of support for CORS gets in the way and I do have to fall back to actually configuring a conventional HTTP server, which is by no means a hard thing to do but still slows things down a bit.
I just feel that the proposed --cors option is a good bang for the buck as it offers meaningful convenience for the primary use of this existing module with minimal effort required, in terms of both code and maintenance.
I agree a general purpose --header option would be more useful.
Perhaps we could follow the interface of HTTPie which takes them as positional arguments using the Header:Value notation:
$ python -m http.server X-Custom-Header:MyCustomValue
Currently we have the port as positional so we’d need to look for the colon to handle these differently. On the other hand, a separate --header option would be easier to document and implement.
While I understand the rationale of wanting similarity to HTTPie due to its popularity, I think that because HTTP servers and HTTP clients are different (although related) use cases it therefore makes sense that their interfaces could be different. HTTPie has the advantage that it has a URL argument to separate its option flags from what it then calls “items” (form fields or request headers):
http [flags] [METHOD] URL [ITEM [ITEM]]
In the case of http.server we don’t have this arrangement, we have currently only one explicit positional argument for port:
python -m http.server [OPTIONS] [port]
As you noted if we used the “bare” style of headers we’d have to distinguish them from the port argument. This would be easy enough to do right now, since port is numeric and headers are alphanumeric with a : inside. However, it would possibly make adding future arguments more difficult. For instance suppose instead of just allowing the --bind argument we also allowed a positional argument of 127.0.0.1:8000 (which allows you to specify the binding interface and port in one argument), this would clash and become ambiguous if we also used the “bare” style of headers. I also think the philosophy of “explicit is better than implicit” applies here, using an explicit --header or -H argument is cleaner to understand, document, and implement, as you noted.
Thanks for looking into that. Let’s do an explicit --header / -H, without --cors.