New command line tool: HTTP server optimized for p2p file transfers
 

Hello everyone.
I would like to announce a new command line tool I have developed for Linux. It is a simple HTTP server which has been optimized for decentralized point to point file transfer use.
A typical use case would be to send a large file by email, the sender can run the server on his/her computer and email a link to the file where the receiver can download the link with any web browser or with wget. There are a number of added features to facilitate this usage.

The entire program is written in C.

More information and source code can be located here:
http://betteros.org/sw/http.php


Enjoy, and tell me what you think.

I would default to die after one transfer and a port other then 80.
I would display usage if no command line arguments were used.
The show_addr function does not display the correct IP address.
Improvements might be to add a compression option if transferring large or multiple files.

Thank you for your feedback.
You may be right, it could make sense to die after one transfer by default, I will think about that. However, I can not think about another default port other than 80. I imagine very very few people will actually find it useful to run it on port 80 and it will fail if the user has something like Apache already running, but I cannot think of another sensible default (other than just picking on arbitrarily).
Displaying usage by default is probably a good idea. I will change that.
The show_addr function should work, and it worked in my testing, however, of course it only shows the LAN IP (if behind a NAT). It also shows the address of "eth0" by default, in order to display some other interface you have to specify it with -i <if> on the command line.

Built-in compression or encryption would be useful I agree, but there are already good Linux tools for this and I would prefer not to add any external dependencies.

Thanks!

Port 8080 is probably one of the next most used. Using a port >1024 means non root users can run the program too.

I suppose, it does make sense since that port is official designated as the HTTP alternative by IANA. Or I could just force the user to choose one explicitly, which defaulting to port 80 sort of does anyway since unless users are willing to run it as root. Something I have to think about though... choosing good defaults is hard....

Ok, I made a few changes and uploaded a new version.
It now dies after one connection by default. I added a new command line argument (-c) to emulate the old behavior.
It now displays the usage page if run with no arguments.
The usage page now displays information about what the defaults are. Hopefully this can help people understand the default behavior and understand how to change it to suit their purposes easier.
I did not change the default port, but I may in the future.