Sōzu HTTP reverse proxy, configurable at runtime, fast and safe, built in Rust. It is awesome! Ping us on gitter to know more

Overview

Sōzu · Join the chat at https://gitter.im/sozu-proxy/sozu Build Status

Sōzu is a lightweight, fast, always-up reverse proxy server.

Why use Sōzu?

  • Hot configurable: Sozu can receive configuration changes at runtime through secure unix sockets.
  • Upgrades without restarting: Sozu is always-up, meaning it upgrades itself while still processing requests.
  • Handles SSL: Sozu handles SSL, so your backend servers can focus on what they do best.
  • Protects your network: Sozu protect backends by shielding them behind the reverse proxy, limiting direct network access. Sozu uses Rust, a language primed for memory safety. And even if a worker is exploited, sozu workers are sandboxed.

Building and starting

Requirements:

  • openssl 1.0.1 or above (including libraries/includes, ie apt install libssl-dev / rpm install openssl-devel

You can create the required executables like this:

cd ctl && cargo build; cd ../bin && cargo build

This will create the sozu executable for the reverse proxy, and sozuctl to command it.

To start the reverse proxy:

cd bin;
../target/debug/sozu start -c config.toml

You can edit the reverse proxy's configuration with the config.toml file. You can declare new applications, their frontends and backends through that file, but for more flexibility, you should use the command socket (you can find one end of that unix socket at the path designed by command_socket in the configuration file).

sozuctl has a few commands you can use to interact with the reverse proxy:

  • soft shutdown (wait for active connections to stop): sozuctl -c config.toml shutdown
  • hard shutdown: sozuctl -c config.toml shutdown --hard
  • display the list of current configuration messages: sozuctl -c config.toml state dump
  • save the configuration state to a file: sozuctl -c config.toml state save -f state.json

For OSX build

Mac OS uses an old version of openssl, so we need to use one from Homebrew:

brew install openssl
brew link --force openssl

If it does not work, set the following environment variables before building:

export OPENSSL_LIB_DIR=/usr/local/opt/openssl/lib/
export OPENSSL_INCLUDE_DIR=/usr/local/opt/openssl/include/

Logging

The reverse proxy uses env_logger. You can select which module displays logs at which level with an environment variable. Here is an example to display most logs at info level, but use trace level for the HTTP parser module:

RUST_LOG=info,sozu_lib::parser::http11=trace ./target/debug/sozu

Exploring the source

  • lib/: the sozu_lib reverse proxy library contains the event loop management, the parsers and protocols
  • bin/: the sozu executable wraps the library in worker processes, and handle dynamic configuration
  • ctl/: the sozuctl executable can send commands to the reverse proxy

License

Copyright (C) 2015-2018 Geoffroy Couprie, Clément Delafargue and Clever Cloud

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, version 3.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

Comments
  • Unable to compile : openssl errors

    Unable to compile : openssl errors

    I'm trying to compile sozu on debian testing but i have these errors :

       Compiling sozu-lib v0.1.1
    error: no associated item named `get_2048_256` found for type `openssl::dh::Dh` in the current scope
       --> /home/mathieu/.cargo/registry/src/github.com-1ecc6299db9ec823/sozu-lib-0.1.1/src/network/tls.rs:433:11
        |
    433 |     match Dh::get_2048_256() {
        |           ^^^^^^^^^^^^^^^^
    
    error: no method named `set_ecdh_auto` found for type `openssl::ssl::SslContextBuilder` in the current scope
       --> /home/mathieu/.cargo/registry/src/github.com-1ecc6299db9ec823/sozu-lib-0.1.1/src/network/tls.rs:441:13
        |
    441 |     context.set_ecdh_auto(true);
        |             ^^^^^^^^^^^^^
    
    error: no associated item named `get_2048_256` found for type `openssl::dh::Dh` in the current scope
       --> /home/mathieu/.cargo/registry/src/github.com-1ecc6299db9ec823/sozu-lib-0.1.1/src/network/tls.rs:587:11
        |
    587 |     match Dh::get_2048_256() {
        |           ^^^^^^^^^^^^^^^^
    
    error: no method named `set_ecdh_auto` found for type `openssl::ssl::SslContextBuilder` in the current scope
       --> /home/mathieu/.cargo/registry/src/github.com-1ecc6299db9ec823/sozu-lib-0.1.1/src/network/tls.rs:594:9
        |
    594 |     ctx.set_ecdh_auto(true);
        |         ^^^^^^^^^^^^^
    
    error: aborting due to 4 previous errors
    
    error: Could not compile `sozu-lib`.
    

    Any idea how to solve this ?

    opened by mcorbin 16
  • Metrics: backend.connections reports huge (and incorrect) values

    Metrics: backend.connections reports huge (and incorrect) values

    screenshot-2018-4-18 warp10 quantum

    As you can see on this picture, backend.connections increased at some point and never really went down. The unit value on the left is partially hidden, the actual value reported is: 36893488147419103000.

    The setup has two workers. Each worker reports 18446744073709552000 backend connections, which gives the number above if we multiply it by the number of workers.

    The value never decreased and is still that high a few hours after.

    bug 
    opened by BlackYoup 13
  • correct systemd integration

    correct systemd integration

    In gitlab by @Geal on Nov 15, 2016, 11:07

    right now, we have a simple systemd service file, for a single process writing logs to stdout. In the near future, the proxy will use a main process with a few worker processes.

    Questions:

    • how to make a service file work correctly with a multiprocess arch?
    • how to handle logging from the workers?

    apparently, there's a KillMode=mixedoption to kill all the process in the cgroup. Ideally, in the case of a restart, the parent process would receive the signal and restart the workers itself, since it knows how to give them the relevant data. Right now, the workers will log on stdout, but they could send messages to syslog instead.

    @keruspe @divarvel what do you think?

    opened by Geal 13
  • Thread 'main' panicked

    Thread 'main' panicked

    I open this issue with the current docker image. Maybe the problem is corrected outside docker.

    Environment :

    root@vertx:~/vertx-voting-app# docker version
    Client:
     Version:      17.05.0-ce
     API version:  1.29
     Go version:   go1.7.5
     Git commit:   89658be
     Built:        Thu May  4 22:10:54 2017
     OS/Arch:      linux/amd64
    
    Server:
     Version:      17.05.0-ce
     API version:  1.29 (minimum version 1.12)
     Go version:   go1.7.5
     Git commit:   89658be
     Built:        Thu May  4 22:10:54 2017
     OS/Arch:      linux/amd64
     Experimental: false
    

    The Linux is Ubuntu 16.04

    root@vertx:~/vertx-voting-app# uname -a
    Linux vertx 4.4.0-79-generic #100-Ubuntu SMP Wed May 17 19:58:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
    

    The application comes from https://github.com/Treeptik/vertx-voting-app

    And the stacktrace:

    sozu_1          | 2017-06-19T19:29:39Z	6122965723685	9	DEBUG	HTTP-0	sozu_lib::network::protocol::http	2f5e0dfd-6460-492e-9cb7-a8b6ecec1c89	backend-vote		BACK [36->20036]: wrote 15 bytes of 15
    sozu_1          | thread 'main' panicked at 'investigating single buffer usage: the front->back buffer should not be used while parsing and forwarding the response', /sozu-source/lib/src/network/protocol/http.rs:611
    sozu_1          | stack backtrace:
    sozu_1          |    1:     0x5605bbed94dc - std::sys::imp::backtrace::tracing::imp::write::hf33ae72d0baa11ed
    sozu_1          |                         at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
    sozu_1          |    2:     0x5605bbedf2ce - std::panicking::default_hook::{{closure}}::h59672b733cc6a455
    sozu_1          |                         at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:351
    sozu_1          |    3:     0x5605bbedeed4 - std::panicking::default_hook::h1670459d2f3f8843
    sozu_1          |                         at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:367
    sozu_1          |    4:     0x5605bbedf76b - std::panicking::rust_panic_with_hook::hcf0ddb069e7beee7
    sozu_1          |                         at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:555
    sozu_1          |    5:     0x5605bbca7a13 - std::panicking::begin_panic::hcee73e0b293b8c83
    sozu_1          |                         at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:517
    sozu_1          |    6:     0x5605bbda0a0b - <sozu_lib::network::protocol::http::Http<Front>>::back_readable::h4a1246cabf7ecd88
    sozu_1          |                         at /sozu-source/lib/src/network/protocol/http.rs:611
    sozu_1          |    7:     0x5605bbdbefb3 - <sozu_lib::network::http::Client as sozu_lib::network::proxy::ProxyClient>::back_readable::h876c202785470845
    sozu_1          |                         at /sozu-source/lib/src/network/http.rs:272
    sozu_1          |    8:     0x5605bbdf8ff5 - <sozu_lib::network::proxy::Server<ServerConfiguration, Client>>::ready::ha28e851867ca024d
    sozu_1          |                         at /sozu-source/lib/src/network/proxy.rs:532
    sozu_1          |    9:     0x5605bbdf4fc1 - <sozu_lib::network::proxy::Server<ServerConfiguration, Client>>::run::h033dcfd844da99f2
    sozu_1          |                         at /sozu-source/lib/src/network/proxy.rs:415
    sozu_1          |   10:     0x5605bbdcd748 - sozu_lib::network::http::start::h5253c70194772b51
    sozu_1          |                         at /sozu-source/lib/src/network/http.rs:708
    sozu_1          |   11:     0x5605bb929174 - sozu::worker::begin_worker_process::hfe3f858642ef9a0f
    sozu_1          |                         at /sozu-source/bin/src/worker.rs:117
    sozu_1          |   12:     0x5605bb930d4d - sozu::main::h3c24609eeed730d5
    sozu_1          |                         at /sozu-source/bin/src/main.rs:74
    sozu_1          |   13:     0x5605bbee67da - __rust_maybe_catch_panic
    sozu_1          |                         at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
    sozu_1          |   14:     0x5605bbedfed6 - std::rt::lang_start::hd7c880a37a646e81
    sozu_1          |                         at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:436
    sozu_1          |                         at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panic.rs:361
    sozu_1          |                         at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/rt.rs:57
    sozu_1          |   15:     0x5605bb946142 - main
    sozu_1          |   16:     0x7fefa100182f - __libc_start_main
    sozu_1          |   17:     0x5605bb602758 - _start
    sozu_1          |   18:                0x0 - <unknown>
    sozu_1          | 2017-06-19T19:46:04Z	7107772533523	1	INFO	MASTER	received client order AddInstance(Instance { app_id: "backend-sozu-vertxvotingapp", ip_address: "172.18.0.4", port: 80 }) with tag "HTTP"
    sozu_1          | 2017-06-19T19:46:04Z	7107773357481	1	INFO	MASTER	received client order RemoveInstance(Instance { app_id: "backend-sozu-vertxvotingapp", ip_address: "172.19.0.2", port: 80 }) with tag "HTTP"
    
    bug 
    opened by zepouet 12
  • add timeouts to sozuctl commands

    add timeouts to sozuctl commands

    if there was an error handling the command and sozu doe not answer, sozuctl might just block waiting for the answer.

    There's a solution I tested for the status command:

    Commands to update with this:

    • [x] state save
    • [x] state load
    • [x] state dump
    • [x] stop --hard
    • [x] upgrade
    • [x] metrics
    • [x] add application
    • [x] remove application
    • [x] add frontend
    • [x] remove frontend
    • [x] add backend
    • [x] remove backend
    • [x] add certificate
    • [x] remove certificate
    • [x] query
    • [x] logging filter
    opened by Geal 11
  • bad behaviour under load from wrk2

    bad behaviour under load from wrk2

    when using wrk2, the latency reports indicates a lot of timeouts, while sozu (current master at 6f4f67f ) does not indicate any issue:

    $ ~/dev/clevercloud/wrk2/wrk -L -d 30s -c 200 -t 4 -R 10000 http://lolcatho.st:8080
    Running 30s test @ http://lolcatho.st:8080
      4 threads and 200 connections
      Thread calibration: mean lat.: 2825.632ms, rate sampling interval: 10608ms
      Thread calibration: mean lat.: 2827.824ms, rate sampling interval: 10616ms
      Thread calibration: mean lat.: 3427.516ms, rate sampling interval: 11296ms
      Thread calibration: mean lat.: 2830.079ms, rate sampling interval: 10616ms
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency      nanus     nanus   0.00us    0.00%
        Req/Sec     0.00      0.00     0.00    100.00%
      Latency Distribution (HdrHistogram - Recorded Latency)
     50.000%    0.00us
     75.000%    0.00us
     90.000%    0.00us
     99.000%    0.00us
     99.900%    0.00us
     99.990%    0.00us
     99.999%    0.00us
    100.000%    0.00us
    
      Detailed Percentile spectrum:
           Value   Percentile   TotalCount 1/(1-Percentile)
    
           0.000     1.000000            0          inf
    #[Mean    =          nan, StdDeviation   =          nan]
    #[Max     =        0.000, Total count    =            0]
    #[Buckets =           27, SubBuckets     =         2048]
    ----------------------------------------------------------
      19800 requests in 30.25s, 623.75MB read
      Socket errors: connect 0, read 0, write 0, timeout 2114
    Requests/sec:    654.45
    Transfer/sec:     20.62MB
    

    I put the access logs in a file, it reports 19775 successful HTTP requests (status 200, response times between 20ms and 120ms).

    Here is my configuration:

    #log_level = "info,sozu_lib::parser::http11=trace"
    log_level = "info"
    log_target = "stdout"
    log_access_target = "file:///Users/geal/dev/rust/projects/yxorp/bin/sozu-access.log"
    
    command_socket = "./command_folder/sock"
    
    command_buffer_size = 16384
    max_command_buffer_size = 163840
    
    worker_count = 1
    
    worker_automatic_restart = false
    handle_process_affinity = false
    
    max_connections = 500
    max_buffers = 1200
    buffer_size = 16384
    
    [http]
    address = "127.0.0.1"
    port = 8080
    
    [applications]
    [applications.MyApp]
    hostname = "lolcatho.st"
    backends = [ "127.0.0.1:1026" ] # list of IP/port
    

    I set the open files limit to 2048. The backend is a nginx server returning a static html page (32769 bytes).

    From earlier runs, it appears that nginx returns Connection: keep-alive in each response, except the last ones.

    I suspect there's an issue in the way sozu is handling the requests from wrk2 (maybe around the keep-alive/"Connection: close" behaviour), but I don't have the info yet.

    This is annoying, because wrk2 is a really nice way to benchmark web servers, so it should work properly with sozu.

    performance 
    opened by Geal 10
  • investigate smarter buffer usage

    investigate smarter buffer usage

    In gitlab by @Geal on Nov 3, 2016, 16:54

    untested idea: the buffers are mainly used to parse headers, while the rest of the data can be transferred by splice() (on Linux). So keeping two buffers (one for front->back, one for back->front) could be a bit wasteful. The proxy could request one buffer from the pool to parse request headers, transfer the headers to the backend, then:

    • if it is a headers-only request, reuse the buffer directly to parse back->front
    • if it is a request with a full body, return the buffer to the pool, use splice to copy the body to the backend
    • if it is a chunking request, return the buffer to the pool, copy and parse each chunk header in a fixed stack buffer (is there a limit to chunk size so we can infer a limit for the chunk header's size?), then use splice to copy the chunk's content

    a few unknowns in this:

    • how many changes to the current code it would require?
    • how to keep compatibility with other platforms?
    • can we really use the same buffer for back and front?
    opened by Geal 10
  • implement the `get_executable_path` function for freeBSD

    implement the `get_executable_path` function for freeBSD

    Hello, I wanted to try sozu on my server, unfortunately freeBSD does not seem to be supported because of this get_executable_path function.

    I’ve never done this kind of unsafe / C call code in rust so please tell me if something is wrong with my code :)

    opened by irevoire 9
  • Workers don't correctly detect closed connections and try to reuse them

    Workers don't correctly detect closed connections and try to reuse them

    I mostly open this issue to track it, I'll try to go deeper into why it behaves like this but right now, I don't have much clues.

    I'm using sozu in front of a plex instance (plex being a self hosted netflix like). During video streaming, some requests hang and never complete. I have only 1 backend and 1 worker.

    I don't really know from where this comes from. With haproxy in front of the plex instance, I can't reproduce the problem.

    The last logs after a browser refresh, when the index.html page hangs:

    2017-07-31T22:27:18Z    1219171966852505        8556    DEBUG   TAG-0   sozu_lib::network::protocol::http       b573d867-b590-48d8-82fa-1368ea8d5251    plex            FRONT [Some(Token(6148914691236517219))]: read 492 bytes
    2017-07-31T22:27:18Z    1219171967105692        8556    TRACE   TAG-0   sozu_lib::parser::http11        PARSER  got Connection header: ""keep-alive""
    2017-07-31T22:27:18Z    1219171967422359        8556    TRACE   TAG-0   sozu_lib::network::session      front readable  interpreting client order ConnectBackend
    2017-07-31T22:27:18Z    1219171967500568        8556    DEBUG   TAG-0   sozu_lib::network::session      keepalive, reusing backend connection
    2017-07-31T22:27:18Z    1219171967637816        8556    DEBUG   TAG-0   sozu_lib::network::protocol::http       b573d867-b590-48d8-82fa-1368ea8d5251    plex            BACK [6148914691236517219->6148914691236517718]: wrote 628 bytes of 628
    2017-07-31T22:27:18Z    1219171967676536        8556    DEBUG   TAG-0   sozu_lib::network::protocol::http       b573d867-b590-48d8-82fa-1368ea8d5251    plex            BACK  [6148914691236517219<-6148914691236517718]: read 0 bytes
    2017-07-31T22:27:18Z    1219171967731555        8556    TRACE   TAG-0   sozu_lib::network::session      front writable  interpreting client order Continue
    

    This is not much context. It's just one request that hangs and some other still complete fine (not much though). Reloading the page doesn't help.

    To elaborate on the "other requests still complete fine":

    • I stream a movie
    • The request downloading the video stream hangs at some point (it's one request only).
    • I refresh the page, all assets do not load, some of them hang
    • If I keep refreshing, more and more requests will hang until the index.html file hangs too (with the logs above)
    • If I wait a few minutes (or even a few seconds) and refresh, everything is back to normal

    Maybe it's the keep-alive between the proxy and the backend ? It's easy to reproduce but sometimes it takes 1 minute, some other times it takes 10 minutes.

    I'll try to tcpdump this.

    opened by BlackYoup 9
  • store cluster metrics in a simpler way, query them all

    store cluster metrics in a simpler way, query them all

    Continuation of #783

    This pull request removes what @Geal started to work on but didn't finish. The cluster metrics are now stored without timestamps, which reduces the strain on the memory and thus is cleared only everyday at midgnight. They are stored in a simple binary tree map of the form cluster_or_backend_id -> (key, value)

    The relation between is clusters and backend is tracked in another map of the form backend_id -> cluster_id

    This pull request removes the option to enable the timed collection of metrics.

    to do

    • [x] queries for cluster and backend metrics, providing their ids and metric names.
    • [x] error management on cluster & backend ids provided by the CLI
    • [x] error management alltogether

    solves #790 #789

    enhancement 
    opened by Keksoj 8
  • Introduce rustfmt?

    Introduce rustfmt?

    As the SW is mainly developed for in-house use, I'd understand if you wanted me to leave the arrangement of your sitting room alone.

    However, as a possible contributor, I'd appreciate being able to use rustfmt and not having to hand-indent code to conform to the existing style. Otherwise it would lead to lots of whitespace noise.

    opened by moschroe 8
  • Replace logging layer with tracing

    Replace logging layer with tracing

    For now, Sōzu implements its own two layers of logging :

    • a set of logging macros (info!, debug!, etc)
    • a Logger instantiated in each worker to gather the log events and write them onto 5 possible targets:
      • a UDP address
      • a TCP address
      • a unix socket
      • a file
      • stdout

    Since the birth of Sōzu, the tokio ecosystem has grown to become a defining standard in terms of asynchronous software architecture. It contains its own tracing crate, tracing, compatible with a number of loggers.

    Switching Sōzu's home-made macros and logger will allow for a lot of enhancements down the way (such as structured logging: #437) and remove a great deal of code that is uneasy to maintain.

    This PR aims to perform a drop-in replacement of Sōzu's logging logic, including notably:

    • [x] a naive use of logging-subscriber to print logs to stdout throughout Sōzu
    • [ ] the ability to change the log level during runtime
    • [ ] send logs to all 5 targets (udp, tcp, unix socket, file, stdout)
    enhancement logs 
    opened by Keksoj 2
  • Replace sessions with mux and transport sessions

    Replace sessions with mux and transport sessions

    In the spirit of the HTTP2 milestone, we want to split the functioning of current sessions (who pass the traffic from front socket to back socket) into:

    • transport sessions (TCP)
    • mux (for multiplexing) sessions, which entails:
      • an HTTP "server" (HTTP1 or H2) on the front side
      • one or several HTTP "clients" (HTTP1 or H2) on the backend side (this is multiplexing)
      • routing and multiplexing logic

    Screenshot from 2022-12-05 13-26-36

    enhancement h2 
    opened by Keksoj 0
  • Develop HTX, a generic HTTP representation

    Develop HTX, a generic HTTP representation

    Inspired by HAProxy's htx data format, we want to implement a generic HTTP data representation, in order to store and translate HTTP1 and H2 traffic.

    HTX should be a middle layer for all HTTP traffic.

    enhancement h2 
    opened by Keksoj 0
  • The HTTPS proxy could be refactored and renamed to be a generic SSL proxy

    The HTTPS proxy could be refactored and renamed to be a generic SSL proxy

    With the coming of Http2 and TCP over TLS, we may want to reuse and convert the HTTPS proxy as a generic SSL endpoint that redirects to Http2, Http1.1, or TCP clusters via ALPN.

    Thoughts @FlorentinDUBOIS @Geal ?

    enhancement 
    opened by Wonshtrum 7
  • Trickle up errors instead of directly logging

    Trickle up errors instead of directly logging

    As discovered in this Pull Request:

    • #824

    Errors are too often logged in the middle of low-level functions, when they should rather get trickled up and logged by the logic calling them.

    A good example is in command/src/channel.rs:

    https://github.com/sozu-proxy/sozu/blob/68e38591aaaa11ace37515c0781b8d14b8734ca1/command/src/channel.rs#L119-L132

    This should rather return an anyhow::Result<()> with context, to be handled downstream.

    Feel free to comment below on where this change should be applied (or not applied), with github permalinks. Also, quote this issue in ongoing pull requests.

    enhancement 
    opened by Keksoj 0
Releases(0.14.2)
  • 0.14.2(Dec 8, 2022)

    🌟 Features

    ✍️ Changed

    • Update RPM packaging, see [ 0776217 ], [ 37e90c2 ],
    • Update dependencies and refactor a bunch of source code to prepare h2, see [ a lot of commits below 😛 ]

    ⚡ Breaking changes

    We remove the support of OpenSSL in favor of RusTLS, so the tls provider configurations associated to the selection of a tls provider has been dropped as well, see [ e202d1c ]

    Changelog

    ➕ Added

    • [ 7d9b560 ] add brotli to encoding header values [Emmanuel Bosquet] (2022-11-29)
    • [ 22bf673 ] Add support of OpenSSL 3.0.x [Florentin Dubois] (2022-10-17)
    • [ d8f6b30 ] Add configuration options for OpenSSL TLS provider [Florentin Dubois] (2022-10-20)
    • [ 79755c8 ] Merged https_openssl and https_rustls [Eloi DEMOLIS] (2022-11-17)
    • [ e202d1c ] Remove OpenSSL [Eloi DEMOLIS] (2022-11-17)
    • [ 7118e64 ] import https://github.com/sozu-proxy/sozu-acme into the sozu command line [Emmanuel Bosquet] (2022-12-07)
    • [ 339277d ] update acme-lib and tiny_http dependencies [Emmanuel Bosquet] (2022-12-07)
    • [ da0f667 ] Add codeowners file [Florentin Dubois] (2022-11-30)

    ✍️ Changed

    • [ 0776217 ] Making some updates to RPM build spec and script. [Igal Alkon] (2021-07-31)
    • [ 37e90c2 ] Updating the rpm build script to have two modes of build the packages. [Igal Alkon] (2021-07-31)
    • [ 8997ec2 ] Update changelog to add entry for 0.14.1 [Florentin Dubois] (2022-10-13)
    • [ 073375f ] Unit tests, comments and refactoring of command/src/channel.rs [Emmanuel Bosquet] (2022-10-17)
    • [ e6a4615 ] Update README.md to remove ctl crate and add command one [Florentin Dubois] (2022-10-17)
    • [ a930847 ] Fix typos [Kian-Meng Ang] (2022-11-10)
    • [ 6fdfc18 ] update build scripts with the --locked flag [Emmanuel Bosquet] (2022-12-01)
    • [ 6f38476 ] Update dependencies [Florentin Dubois] (2022-12-01)
    • [ ae8ffe7 ] Update behaviour of add_certificate to skip already loaded certificate [Florentin Dubois] (2022-12-02)
    • [ aef7baa ] Rename variables l to listener on command/src/config [Florentin Dubois] (2022-12-02)
    • [ 19c4f70 ] Use rustfmt to format project [Florentin Dubois] (2022-12-02)
    • [ 72bb233 ] fullfill syntax TODOs [Emmanuel Bosquet] (2022-11-17)
    • [ dceea6f ] log ConnectionError with thiserror [Emmanuel Bosquet] (2022-11-22)
    • [ a7697ff ] Use listener cert when https front lacks cert [Ion Agorria] (2022-11-25)
    • [ 42c548b ] set a TODO to handle EINPROGRESS error when connecting to backend [Emmanuel Bosquet] (2022-11-25)

    🚀 Refactored

    • [ c882946 ] processing messages between main process and CLI [Emmanuel Bosquet] (2022-10-20)
    • [ e90cc52 ] ctl: display response message for successful ProxyRequestOrder [Emmanuel Bosquet] (2022-10-25)
    • [ 69aac18 ] http session: clean-up session creation [Emmanuel Bosquet] (2022-11-08)
    • [ f31c894 ] tcp session: clean-up session creation [Emmanuel Bosquet] (2022-11-08)
    • [ 94994a3 ] htts_openssl session: clean-up session creation [Emmanuel Bosquet] (2022-11-08)
    • [ f5c6cf5 ] https_rustls session: clean-up session creation [Emmanuel Bosquet] (2022-11-08)
    • [ a4dc22e ] remove useless front_socket_mut functions on tcp and http Session [Emmanuel Bosquet] (2022-11-08)
    • [ 3e2f445 ] full error propagation on ConfigState::handle_order() [Emmanuel Bosquet] (2022-11-16)
    • [ 42986fd ] Error propagation on ScmSocket and Channel [Emmanuel Bosquet] (2022-11-17)
    • [ edfa1b4 ] remove obsolete comment about main process crashing [Emmanuel Bosquet] (2022-11-17)
    • [ bfc4884 ] replace ConnectionError with anyhow::Result [Emmanuel Bosquet] (2022-12-05)
    • [ 59bb989 ] merge client loop creation logic in the accept_clients function [Emmanuel Bosquet] (2022-12-05)
    • [ a6c7c9f ] error propagation on getting 404 and 503 answers from file system [Emmanuel Bosquet] (2022-11-17)
    • [ 5d83eef ] define the ClusterId type only once [Emmanuel Bosquet] (2022-11-17)
    • [ 605b95e ] abstract out the function reset_loop_time_and_get_timeout [Emmanuel Bosquet] (2022-11-25)
    • [ 2959876 ] abstract out the function read_channel_messages_and_notify [Emmanuel Bosquet] (2022-11-25)
    • [ 7743eba ] abstract out the functions zombie_check and shutting_down_complete [Emmanuel Bosquet] (2022-11-25)
    • [ c5e2262 ] add fields to Server for a clearer loop flow [Emmanuel Bosquet] (2022-11-25)
    • [ 96b90c9 ] clearer syntax on read_channel_messages_and_notify, comments [Emmanuel Bosquet] (2022-11-28)
    • [ 1aee08d ] create ConnectionError::MioConnectError [Emmanuel Bosquet] (2022-11-28)
    • [ 33b3e5f ] Abstract out notify proxys (#842) [Emmanuel Bosquet] (2022-11-30)

    💪 First works on H2

    • [ 6bdb937 ] Rename HTTPS states, remove Option around State, rename https.rs [Eloi DEMOLIS] (2022-11-17)
    • [ a819fa3 ] Add Invalid State in HTTPS, add ALPN to Rustls ServerConfig [Eloi DEMOLIS] (2022-11-17)
    • [ 26f7d15 ] Make way for H2 with Alpn switch [Eloi DEMOLIS] (2022-11-17)
    • [ ec31f82 ] make RouteKey a common struct, make use of its methods [Emmanuel Bosquet] (2022-11-17)

    ⛑️ Fixed

    • [ 790f96b ] prevent concurrent testing in the github CI [Emmanuel Bosquet] (2022-12-01)
    • [ 719b637 ] ScmSocket::set_blocking updates its blocking field, takes &mut self [Emmanuel Bosquet] (2022-12-01)
    • [ 2624a43 ] Fix Sessions close: [Eloi DEMOLIS] (2022-12-02)

    🥹 Contributors

    • @alkavan made their first contribution in https://github.com/sozu-proxy/sozu/pull/693
    • @kianmeng made their first contribution in https://github.com/sozu-proxy/sozu/pull/830
    • @Wonshtrum
    • @Keksoj
    • @FlorentinDUBOIS

    Full Changelog: https://github.com/sozu-proxy/sozu/compare/v0.14.1...0.14.2

    Source code(tar.gz)
    Source code(zip)
  • 0.14.1(Oct 13, 2022)

    :bookmark: Documentation

    ✍️ Changed

    :book: Changelog

    • 07ccff3 ] Update changelog to add version v0.14.0 [Florentin Dubois] (2022-10-06)
    • 7e223ee ] Rewrite session creation in lifetime_of_a_session.md [Eloi DEMOLIS] (2022-10-11)
    • 50a940a ] Continue work on the documentation, rename listen_token to listener_token [Eloi DEMOLIS] (2022-10-11)
    • a13eb35 ] Finish rewriting existing parts [Eloi DEMOLIS] (2022-10-11)
    • 2b6706c ] Finish the lifetime of a session documentation [Eloi DEMOLIS] (2022-10-12)
    • 3af39a6 ] Update TLS cipher suites [Florentin Dubois] (2022-10-12)
    • 693bc84 ] Update rust edition to 2021 [Florentin Dubois] (2022-10-13)
    • 8f4449c ] Update command dependencies [Florentin Dubois] (2022-10-13)
    • e14109b ] Update rust edition to 2021 [Florentin Dubois] (2022-10-13)
    • 339ed21 ] Update rust edition to 2021 [Florentin Dubois] (2022-10-13)
    • f064d8b ] Update binary dependencies [Florentin Dubois] (2022-10-13)
    • 0e3fffe ] Fix a blocking clippy suggestion [Florentin Dubois] (2022-10-13)

    🥹 Contributors

    • @Wonshtrum
    • @Keksoj
    • @FlorentinDUBOIS

    Full Changelog: https://github.com/sozu-proxy/sozu/compare/v0.14.0...0.14.1

    Source code(tar.gz)
    Source code(zip)
Owner
sōzu
Everything about sōzu, the HTTP reverse proxy with runtime reconfiguration
sōzu
HTTP Proxy based solution for real-time interception and prioritization of SQL queries.

starproxy ⚠️ starproxy is a prototype: Not currently used in production, but will likely be some day. Table of Contents starproxy Table of Contents Ba

Will Eaton 5 Mar 6, 2023
Volt - A powerful, fast and memory safe package manager for the web

Volt - A powerful, fast and memory safe package manager for the web

Volt Package Manager 811 Dec 30, 2022
A blazingly fast HTTP client with a magnificent request building syntax, made for humans.

?? glue Make requests, select JSON responses, nest them in other requests: A magnificent syntax for blazingly fast cli HTTP calls, made for humans. Ta

Michele Esposito 4 Dec 7, 2022
Perseus is a blazingly fast frontend web development framework built in Rust with support for major rendering strategies

Perseus is a blazingly fast frontend web development framework built in Rust with support for major rendering strategies, reactivity without a virtual DOM, and extreme customizability

arctic_hen7 1.2k Jan 8, 2023
⚡ A Blazingly-Fast Static Site Generator, built with Rust.

Stuart A Blazingly-Fast Static Site Generator. Download Now » Stuart is a very fast and flexible static site generator, with build times as low as 0.1

William Henderson 5 Nov 25, 2022
A filter proxy for StatsD

statsd-filter-proxy-rs statsd-filter-proxy-rs is efficient and lightweight StatsD proxy that filters out unwanted metrics to a StatsD server. Why "If

Alan Ning 20 Mar 20, 2022
A fast static site generator in a single binary with everything built-in. https://www.getzola.org

zola (né Gutenberg) A fast static site generator in a single binary with everything built-in. Documentation is available on its site or in the docs/co

Zola 10.1k Jan 10, 2023
Rust HTTP API Template using PostgreSQL, Redis, RabbitMQ, and Hexagonal Architecture

Rust Template HTTP API Rust API Template using PostgreSQL, Redis, RabbitMQ, and Hexagonal Architecture The following template provides a basic structu

Paulo Bressan 7 Jun 9, 2023
Starlight is a JS engine in Rust which focuses on performance rather than ensuring 100% safety of JS runtime.

starlight Starlight is a JS engine in Rust which focuses on performance rather than ensuring 100% safety of JS runtime. Features Bytecode interpreter

null 453 Dec 31, 2022
Type safe multipart/form-data handling for axum.

axum_typed_multipart Designed to seamlessly integrate with Axum, this crate simplifies the process of handling multipart/form-data requests in your we

Lorenzo Murarotto 10 Mar 28, 2023
Ergonomic and modular web framework built with Tokio, Tower, and Hyper

axum axum is a web application framework that focuses on ergonomics and modularity. More information about this crate can be found in the crate docume

Tokio 7.9k Dec 31, 2022
An async no_std HTTP server suitable for bare-metal environments, heavily inspired by axum

picoserve An async no_std HTTP server suitable for bare-metal environments, heavily inspired by axum. It was designed with embassy on the Raspberry Pi

Samuel Hicks 81 Oct 7, 2023
A cookie manager middleware built on top of tower.

tower-cookies A cookie manager middleware built on top of tower. Example With axum: use axum::{handler::get, Router}; use std::net::SocketAddr; use to

Imbolc 47 Dec 9, 2022
A crate built on top of `axum-sessions`, implementing the CSRF Synchronizer Token Pattern

Axum Synchronizer Token Pattern CSRF prevention This crate provides a Cross-Site Request Forgery protection layer and middleware for use with the axum

null 3 Dec 15, 2022
A highly customizable, full scale web backend for web-rwkv, built on axum with websocket protocol.

web-rwkv-axum A axum web backend for web-rwkv, built on websocket. Supports BNF-constrained grammar, CFG sampling, etc., all streamed over network. St

Li Junyu 12 Sep 25, 2023
Actix Web is a powerful, pragmatic, and extremely fast web framework for Rust.

Actix Web is a powerful, pragmatic, and extremely fast web framework for Rust.

Actix 16.2k Jan 2, 2023
Thruster - An fast and intuitive rust web framework

A fast, middleware based, web framework written in Rust

null 913 Dec 27, 2022
Seed is a Rust front-end framework for creating fast and reliable web apps with an Elm-like architecture.

Seed is a Rust front-end framework for creating fast and reliable web apps with an Elm-like architecture.

null 3.6k Jan 6, 2023
A simple, modular, and fast framework for writing MEV bots in Rust.

What is Artemis? Artemis is a framework for writing MEV bots in Rust. It's designed to be simple, modular, and fast. At its core, Artemis is architect

Paradigm 1.4k Jun 26, 2023