[HN Gopher] Simple Web Server
___________________________________________________________________
Simple Web Server
Author : speckx
Score : 61 points
Date : 2025-04-14 17:43 UTC (5 hours ago)
(HTM) web link (simplewebserver.org)
(TXT) w3m dump (simplewebserver.org)
| bsimpson wrote:
| If you globally install the npm module dhost, you can run it from
| any directory (`dhost`) to start a webserver there.
|
| Python 2 had a similar function (`python -m SimpleHTTPServer`). I
| know there's a Python 3 equivalent, but I don't have it
| memorized.
| bondant wrote:
| python3 -m http.server
| Imustaskforhelp wrote:
| I also use this! like I wanted a backup of my device once to
| my phones when my system was messed up.
|
| and I used this. Though I would prefer a way to keep it
| downloading from where it left because this method ISNT
| reliable for 40 gigs transfer
|
| I am also wondering about this comment in the gist which was
| linked (gist.github.com/willurd/5720255) by olejorgenb which
| is
|
| Limiting request to a certain interface (eg.: do not allow
| request from the network)
|
| python -m http.server --bind 127.0.0.1
|
| Like what does that really do? Maybe its also nice, IDK?
| bsimpson wrote:
| 127.0.0.1 means "self" in IP. Presumably that means that it
| if you browse to your IP address from your computer it will
| work, but from your phone it will not.
|
| I usually do the opposite - 0.0.0.0 - which allows
| connections from any device.
| kzahel wrote:
| I wrote the original version of this "simple web server" app
| (https://chromewebstore.google.com/detail/web-server-for-
| chro...) because the built-in python http server is a bit
| buggy. It would hang on some connections when loading a
| webpage with a lot of small assets. I was surprised how many
| people found it useful. More so when Chrome web apps were
| supported on other platforms (mac/linux/windows).
| vyrotek wrote:
| I use serve
|
| https://www.npmjs.com/package/serve
| bangaladore wrote:
| Should support self-signed HTTPs ideally. IIRC there a quite a
| few (some?) web features that do not function unless the page is
| served over HTTPs.
|
| That would certainly make this more useful than `python3 -m
| http.server`.
| zamadatix wrote:
| It does. It also includes a dozen other things beyond what that
| one liner would do. Keep in mind, if it fits with what you're
| trying to test/how you're trying to develop, just doing things
| on http://localhost will be treated as a secure origin in most
| browsers these days.
|
| There does seem to be a weird limitation that you can't enable
| both HTTP and HTTPS on the same port for some reason. That
| should be easy enough to code a fix for though.
| bangaladore wrote:
| > HTTP and HTTPS on the same port
|
| Do any real web servers support this?
|
| Its the same transport (TCP assuming something like HTTP 1.1)
| and trying to mix HTTP and HTTPS seems like a difficult thing
| to do correctly and securely.
| p4bl0 wrote:
| Theoretically it would be feasible with something like
| STARTTLS that allows to upgrade a connection (part of SMTP
| and maybe IMAP) but browsers do not support this as it is
| not part of standard HTTP.
| ekr____ wrote:
| It actually _is_ part of standard HTTP [0], just not part
| of commonly implemented HTTP.
|
| The basic difference between SMTP and HTTP in this
| context is that email addresses do not contain enough
| information for the client to know whether it should be
| expecting encrypted transport or not (hence MTA-STS and
| SMTP/DANE [1]), so you need to negotiate it with STARTTLS
| or the like, whereas the https URL scheme tells the
| client to expect TLS, so there is no need to negotiate,
| you can just start in with the TLS ClientHello.
|
| In general, it would be inadvisable at this point to try
| to switch hit between HTTP and HTTPS based on the initial
| packets from the client, because then you would need to
| ensure that there was no ambiguity. We use this trick to
| multiplex DTLS/SRTP/STUN and it's somewhat tricky to get
| right [2] and places limitations on what code points you
| can assign later. If you wanted to port multiplex, it
| would be better to do something like HTTP Upgrade, but at
| this point port 443 is so entrenched, that it's hard to
| see people changing.
|
| [0] https://www.rfc-editor.org/rfc/rfc7230#section-6.7.
| [1] https://datatracker.ietf.org/doc/html/rfc8461
| https://datatracker.ietf.org/doc/html/rfc7672 [2]
| https://datatracker.ietf.org/doc/html/rfc7983
| bangaladore wrote:
| > In general, it would be inadvisable at this point to
| try to switch hit between HTTP and HTTPS based on the
| initial packets from the client, because then you would
| need to ensure that there was no ambiguity.
|
| Exactly my original point. If you really understand the
| protocols, there is probably zero ambiguity (I'm assuming
| here). But with essentially nothing to gain from
| supporting this, its obvious to me that any minor risk
| outweighs the (lack of) benefits.
| dextercd wrote:
| NGINX detects attempts to use http for server blocks
| configured to handle https traffic and returns an
| unencrypted http error: "400 The plain HTTP request was
| sent to HTTPS port".
|
| Doing anything other than disconnecting or returning an
| error seems like a bad idea though.
| zamadatix wrote:
| I think what I had seen before was replacing the http
| variant of the "bad request" page with a redirect to the
| HTTPS base URL something akin to
| https://serverfault.com/a/1063031. Looking at it now this
| is probably more "hacky" than it'd be worth and, as you
| note, probably comes with some security risks (though for a
| local development app like this maybe that's acceptable
| just as using plain HTTP otherwise is), so it does sense
| that's not an included feature after all.
| bangaladore wrote:
| I don't think that really applies here.
|
| In general the way that works is user navigates to
| http://contoso.com which implicitly uses port 80. Contoso
| server/cdn listening on port 80 redirects them through
| whatever means to https://contoso.com which implicitly
| uses 443.
|
| I don't see value on both being on the same port. Why
| would I ever want to support this when the http: or
| https: essentially defines the default port.
|
| Now ofcourse someone could go to http://contoso.com:443,
| but WHY would they do this. Again, failing to see a
| reason for this.
| zamadatix wrote:
| I (and the provided link) are not referring to
| http://example.com:80 to https://example.com:443 type
| redirects, though those are certainly nice too. They are,
| indeed, solely about http://example.com:443 to
| https://example.com:443 type redirects and what those can
| provide.
|
| The "why/value" is usually in clearly handling accidents
| in hardcoding connection info, particularly for local
| API/webdev environments where you might pass connection
| information as an object/list of parameters rather than
| normal user focused browser URL bar entry. The upside is
| a connection error can be a bit more opaque than an
| explicit 400 or 302 saying what happened or where to go
| instead. That's the entire reason webservers tend to
| respond with an HTTP 400 in such scenarios in the first
| place.
|
| Like I said though, once I remembered this was more a
| "hacky" type solution to give an error than built-in
| protocol upgrade functionality I'm not so sure the small
| amount of juice would actually be worth the relatively
| complicated squeeze for such a tool anymore.
| woleium wrote:
| You can in fact run http, https (and ssh and many others)
| on the same port with SSLH (its in debian repos) SSLH will
| forward incoming connections based on the protocol detected
| in the initial packets. Probes for HTTP, TLS/SSL (including
| SNI and ALPN), SSH, OpenVPN, tinc, XMPP, SOCKS5, are
| implemented, and any other protocol that can be tested
| using a regular expression, can be recognised
|
| https://github.com/yrutschle/sslh
| dpz wrote:
| https://gist.github.com/willurd/5720255
| p4bl0 wrote:
| I was going to mention busybox httpd and php -S, but this list
| has them already :).
| dark-star wrote:
| cd /some/dir && python -m http.server 8080
| __fst__ wrote:
| python3 -m http.server -d /path/to/dir
| rad_gruchalski wrote:
| Don't forget 8080. http.server binds on port 8000 by default
| :].
| disambiguation wrote:
| docker pull nginx
| enriquto wrote:
| mini_httpd -p 8080 # and no need to install a whole python
| interpreter
| smusamashah wrote:
| I use voidtools Everything on windows for instant file lookup. It
| has an Http server built in. Whenever browser complains about a
| feature only available via webserver url, not local file, it
| comes handy. Open everything webserver, enter name of the file
| and click.
| starik36 wrote:
| I've been using Everything forever and never knew about this
| feature. Thanks!
| nasso_dev wrote:
| For those who have Rust, I like miniserve[1]:
| cargo install --locked miniserve miniserve
| path/to/directory
|
| [1]: https://github.com/svenstaro/miniserve
| elcritch wrote:
| Cool project! Setting up a quick local HTML server can be
| annoying.
|
| Alas it looks like it's web/electron based. :/ Downloading it and
| yep, 443.8 MB on MacOS. The Linux one is a bit better at 183.3
| MB.
|
| Electron really should get a kickback from disk manufacturers! ;)
|
| Shameless plug, I've been working on a HTML inspired lightweight
| UI toolkit because I'm convinced we can make these sort of apps
| and they should only be ~10-20 MB [1] with nice syntax,
| animation, theming, etc. I'm finally making a suite of widgets.
| Maybe I can make a basic clone of this! Bet I could get in <
| 10MB. :)
|
| 1: https://github.com/elcritch/figuro
| tredre3 wrote:
| Figuro is like Sciter but for Nim?
| elcritch wrote:
| Sorta! It didn't start out that way but I've been building
| more from HTML overtime but keeping it fast and lightweight.
| I've cherry picked a subset of HTML like CSS grids which add
| a lot of layout power without tons of normal HTML hacks.
|
| I want to try adding a JavaScript runtime with simple DOM
| built on Figuro nodes instead. But there's some issues with
| Nim's memory management and QuickJs.
| cosmotic wrote:
| Funny the bulk of the server is vestigial client code.
| elcritch wrote:
| Figures, though I suspect that code only makes up a fraction
| of the binary size. Assuming it's electron most of that bulk
| is chromium bits.
| tyzoid wrote:
| My usual go-to for a quick static server is:
|
| python -m http.server
|
| But variations exist for a lot of languages. Php has one built-
| in too
| zikduruqe wrote:
| Don't forget bash. #!/bin/bash
| while :; do nc -l 80 < index.html; done
| xmodem wrote:
| I was about to down-vote you, but that would be unfair, as
| this has roughly the typical level of correctness of most
| bash scripts.
| Hyperlisk wrote:
| This looks nice with a friendly UI. I've been very happy with
| Caddy[1], but this seems like something I might recommend to
| someone that is new to the web environment.
|
| [1] https://caddyserver.com/docs/quick-starts/static-files
| lukan wrote:
| Or someone who has chromeOS not in dev mode.
|
| I use SimpleWebServer there since 6 years or something and it
| just works.
| Ingon wrote:
| For a second there, I read it as static web server [1], which is
| actually pretty cool itself
|
| 1: https://static-web-server.net/
___________________________________________________________________
(page generated 2025-04-14 23:00 UTC)