az107/hteapot

A simple and quick web server writen in Rust

HteaPot HTTP Server

Spanish | English

HteaPot is a simple HTTP server written in Rust. It allows you to serve static files and handle basic HTTP requests.

Features

• Serve static files from a specified root directory
• Configurable server port and host
• Basic logging of incoming requests

Usage

1. Clone the repository:

git clone <repository_url>

2. Build the project:

cargo build --release

Run the server with a configuration file:

Copy code
./target/release/hteapot <config_file_path>

Configuration

You can configure the server using a TOML file. Here's an example configuration:

[HTEAPOT]
port = 8081 # The port on which the server will listen for incoming connections.
host = "localhost" # The host address to bind the server to. 
root = "public" # The root directory from which to serve files.

Contributing

Contributions are welcome! Feel free to open issues or submit pull requests.

License

This project is licensed under the MIT License - see the LICENSE file for details.

hteapot's Issues

Add load balancing to proxy

Add load balancing capabilities to proxy mode
at the moment round robin will be enough

OS error 11 with big payloads

When a big payload body is sended the write_all función returns an error 11 closing the socket

Close server gracefully

Currently, the hteapot HTTP server is terminated by pressing Ctrl+C, which abruptly stops the process. This method does not allow for a graceful shutdown, potentially leading to:

•	Loss of in-flight requests
•	Incomplete logging
•	Corrupted data

Objective:

Implement a more graceful shutdown process for the hteapot HTTP server. The new shutdown mechanism should:

1.	Allow the server to finish processing ongoing requests.
2.	Close all active connections cleanly.
3.	Perform any necessary cleanup tasks (e.g., flushing logs, saving state).
4.	Notify connected clients about the shutdown if applicable.

Acceptance Criteria:

•	Pressing Ctrl+C should initiate the graceful shutdown process.
•	The server should log a message indicating that the shutdown process has started.
•	All in-flight requests should be completed before the server stops.
•	All resources should be properly released.
•	The process should exit only after all shutdown tasks are completed.

Additional Notes:

•	Consider using signal handling (e.g., SIGTERM) to trigger the graceful shutdown.
•	Ensure that the implementation does not introduce significant delays in the shutdown process.

Reference:

Proper way to close TcpStream

Multiple server instances

The server should have the capability to deploy/start multiple servers using a configuration file.

Proposed Configuration File:

[HTEAPOT]
[[server]]
port = 8081
host = "0.0.0.0"
root = "public"
threads = 5
cache = true
cache_ttl = 3600

[server.proxy]
"/test" = "http://example.com"
"/google" = "http://google.com"

[[server]]
port = 8082
host = "0.0.0.0"

[server.proxy]
"/" = "http://ifconfig.co" # This will override all proxies and local requests

Currently, the configuration file works as follows:

[HTEAPOT]
port = 8081
host = "0.0.0.0"
root = "public"
threads = 5
cache = true
cache_ttl = 3600

[proxy]
"/test" = "http://example.com"
"/google" = "http://google.com"

Objective:

Update the configuration file to support setting up multiple servers, allowing unique details for each server instance, such as port, host, and proxy rules.

Proxy path

The proxy configuration is currently set up to only redirect requests that exactly match the specified paths in the configuration. Any other requests that do not match are attempted to be resolved locally.

For example:

•	A request to /test is redirected through the proxy according to the configuration.
•	A request to /test/file.js, however, does not match the exact configuration and is therefore resolved locally rather than being sent through the proxy.

Ideally, the proxy should be configured to handle more complex routing rules. It should be capable of redirecting not just exact matches but also any sub-paths or related files associated with the specified path. For instance:

•	Both /test and any sub-paths like /test/file.js should be redirected through the proxy, ensuring that all relevant resources are handled consistently.

This would provide more comprehensive coverage and ensure that all related resources are properly managed by the proxy, preventing any unexpected local resolution of requests.