Messages in this thread | | | Date | Thu, 10 Jun 1999 10:19:05 +0200 (CEST) | From | Justin Ossevoort <> | Subject | Re: khttpd |
| |
Ever thought about strict firewalling by someone's provider. For system administrators of large public networks it is normal to close port 1024 and lower, and explicitly allow access over port 80, 21.. (and possible other services). So we would generally want to stick to port 80. But if we _would_ use eg. port 81, we would still need/want a user_space deamon. And here we are again for it would have to check if it is supposed to load that file (someone tries to fetch other stuff over port 81), and it would all in all be better to just integrate the code in the main khttpd. And think of all the fuss you would get from using another port, you would have to write you pages with another port (also you would need to specify the entire URL for these things), or you could let the server take care of it, which would overhead, and that was one of the things we wanted to prevent.
On Thu, 10 Jun 1999, Chris Smith wrote:
> Maybe this is a dumb question, but here goes: > > Why not give khttpd a devoted port? Why go to all these pains to dissect > keep-alive connections and all that, when we can do <IMG > SRC="http://my.server.net:81/banner.gif">? Is that just too easy for > everyone? Is it because the benchmarks we were talking about would be able > to use something like that? > > Just curious, > Chris > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/ >
-- -=( Justin Ossevoort )=- [iq-0@internetionals.demon.nl]
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |