Closed shazow closed 4 years ago
I think you're just looking for caddy file-server --browse
.
(the "file" in file-server misled me when I first tried to find this feature--I would not have expected a file server to render HTML like a normal HTTP server).
Caddy doesn't "render" any HTML. It just responds with the contents of the file. Hence, it is a file server.
Er no, the browsing feature is not what I want, I mean I mostly want a shortcut for quickly running a local webserver for development or easy sharing. file-server
will default to port :80 which isn't quite aligned with that usecase.
Er no, the browsing feature is not what I want,
But earlier:
Caddy 1 also served this usecase with
caddy browse
... I'm confused.
So what is the question then? caddy file-server
lets you customize the interface and port like you said.
If it helps add context, I often see projects like https://github.com/joshuarli/srv pop up and I want to ask "why not just caddy?" and the real answer is "welp, you could type out caddy file-server --browse --listen 127.0.0.1:2015
or you could just type srv
". This proposal is about reducing the delta in the user experience for this use case.
If all you want is less typing, the easiest way to do this is offered by your shell:
alias srv="caddy file-server --listen 127.0.0.1:2015"
Problem solved! And the best part is, everyone can customize it to their liking, and there's no code to write.
I never claimed this was not possible with caddy. My claim was this is a very common usecase, that used to be a little more convenient with caddy1 and is less convenient with caddy2. I could also just install srv
, problem solved! That's not the point, is it?
This response reads to me as "caddy2 does not care about the interactive usecase, it does not need to be convenient." I'll avoid looking for ways to contribute in this vein, thanks.
My claim was this is a very common usecase, that used to be a little more convenient with caddy1 and is less convenient with caddy2.
It's not as common as you think, or as I used to think either, actually. Most people wanted to customize it more, and the v1 command line interface was insufficient for that.
I could also just install srv, problem solved! That's not the point, is it?
I guess not, if you're looking for something simple and self-contained. Installing and learning a separate piece of software is more work than aliasing a command, after all. :)
This response reads to me as "caddy2 does not care about the interactive usecase, it does not need to be convenient."
That's not what interactive means. Interactive means that the user interacts with it. With Caddy, you run the command and then it just runs, no need for further user input. That is, by definition, non-interactive. So I'm not really sure what you're getting at here.
I'll avoid looking for ways to contribute in this vein, thanks.
Sorry you feel offended that your proposal was declined with a simpler, more customizable solution. Nothing personal. You can choose to not contribute but that is sad with open source :(
That's not what interactive means.
Interactive in the sense of a terminal session running interactively as opposed to a daemon being managed non-interactively.
I have not been able to get any of my points across here, I'll assume this is my fault, please don't waste any more of your time on this issue.
Honestly, it's simpler and has better UX if you provide a Caddyfile and tell people to do caddy run
or caddy start
. For a simple file server, that's just a 2 line Caddyfile.
This concrete proposal is part of a higher-level desire to improve the quality of life in caddy2 for interactive use (e.g. quickly spinning up an HTTP localhost server to do some quick development or share some files).
The usecase that traditionally Python served with
python -m SimpleHTTPServer
that so much muscle memory has been created, Caddy 1 also served this usecase withcaddy browse
. Now with caddy2, I believe the closest equivalent iscaddy file-server --listen 127.0.0.1:2015
which is tolerable but frustrating to type several times per week and also somewhat less discoverable (the "file" in file-server misled me when I first tried to find this feature--I would not have expected a file server to render HTML like a normal HTTP server).I would like to propose that we start by adding
caddy browse
(or some other descriptive single-word alias) that runs the equivalent ofcaddy file-server --listen 127.0.0.1:2015
(or whatever Official Caddy Default Userland Port we prefer).Feedback on this proposal is appreciated. I did search other issues but please accept my apologies if this was already raised and addressed and I missed it. I'd be happy to contribute this if the idea is accepted and it's not easily accomplished by somebody else. :)