search

caddyserver / caddy

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
https://caddyserver.com
Apache License 2.0
56.47k stars 3.96k forks source link

Proposal: Add `caddy browse` equivalent shortcut to caddy2 #3478

Closed shazow closed 4 years ago

shazow commented 4 years ago

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 with caddy browse. Now with caddy2, I believe the closest equivalent is caddy 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 of caddy 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. :)

mholt commented 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.

shazow commented 4 years ago

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.

mholt commented 4 years ago

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.

shazow commented 4 years ago

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.

mholt commented 4 years ago

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.

shazow commented 4 years ago

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.

mholt commented 4 years ago

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 :(

shazow commented 4 years ago

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.

francislavoie commented 4 years ago

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.