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

Rust's premier framework for working with HTTP/1.x HTTP/2 requests. Includes core features like websockets, keep-alives and slow requests handling

Actix Web


Features

  • Supports HTTP/1.x and HTTP/2
  • Streaming and pipelining
  • Client/server WebSockets support
  • Transparent content compression/decompression (br, gzip, deflate, zstd)
  • Powerful request routing
  • Multipart streams
  • Static assets
  • SSL support using OpenSSL or Rustls
  • Middlewares (Logger, Session, CORS, etc)
  • Includes an async HTTP client
  • Runs on stable Rust 1.46+

Documentation

  • Website & User Guide
  • Examples Repository
  • API Documentation
  • API Documentation (master branch)

Example

Dependencies:

Code:

More examples

  • Basic Setup
  • Application State
  • JSON Handling
  • Multipart Streams
  • Diesel Integration
  • r2d2 Integration
  • Simple WebSocket
  • Tera Templates
  • Askama Templates
  • HTTPS using Rustls
  • HTTPS using OpenSSL
  • WebSocket Chat

You may consider checking out this directory for more examples.

Benchmarks

One of the fastest web frameworks available according to the TechEmpower Framework Benchmark.

License

This project is licensed under either of

  • Apache License, Version 2.0, (LICENSE-APACHE or [http://www.apache.org/licenses/LICENSE-2.0])
  • MIT license (LICENSE-MIT or [http://opensource.org/licenses/MIT])

at your option.

Code of Conduct

Contribution to the actix-web repo is organized under the terms of the Contributor Covenant. The Actix team promises to intervene to uphold that code of conduct.

Issues

Collection of the latest Issues

julianskartor

julianskartor

0

If a service takes long time to complete (longer than value specified byHttpServer::shutdown_timeout to be precise), it seems the server does not properly clean up after itself. In particular, I have an issue with this when the server holds on to a tokio channel sender and I'm waiting for the channel's receiver to get "channel closed" message in a separate tokio task after stopping the server.

Expected Behavior

After calling ServerHandle::stop and waiting until the end of the shutdown_timeout period, all resources held by the server should be dropped.

Current Behavior

Server seems to still hold on to resources.

Possible Solution

None known...

Steps to Reproduce (for bugs)

Given the following example application:

When I call curl -X POST localhost:20000/sleep10 and send SIGINT to the application, it cleanly shutsdown (OK).

If I call curl -X POST localhost:20000/sleep30 and send SIGINT, the application never terminates (BUG).

Context

The end goal for me is to implement graceful shutdown of my application that also runs some other tokio spawned and spawn_blocking tasks.

Your Environment

  • Rust Version: rustc 1.60.0 (7737e0b5c 2022-04-04)
  • Actix Web Version: 4.0.1
  • OS: macOS (12.3.1), Apple M1
januwA

januwA

1

Expected Behavior

Use awc on server to send form-data request for post to another server

Current Behavior

awc doesn't seem to have a similar API

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

  • Rust Version (I.e, output of rustc -V):rustc 1.60.0 (7737e0b5c 2022-04-04)
  • Actix Web Version: 4
marknijboer

marknijboer

C-bug
1

Expected Behavior

I was working with archive video footage that has its modification date set to the date it was shot. In my case a video from 1964. I expected this video to be served without any issues.

Current Behavior

A panic with this message:

Steps to Reproduce (for bugs)

  1. Set the modification date of the file to a date before 1970. E.g.:

  2. Try to access that file through Actix Files as a named file.

Your Environment

Running in production on Ubuntu Linux (5.4.0-107-generic).

matklad

matklad

0

I've noticed firestorm dependency in Cargo.lock of my application. This dependency comes from actix-router. My understanding is that this is a dev-tool used for internal profiling of actix-router.

I understand that it is a no-op crate by default, but I still would prefer not to have this entry in my Cargo.lock to avoid worrying about supply chain attacks and spending time on figuring out why this relatively unknown crate is there.

iyzana

iyzana

needs-investigation
0

(Un)escaping of the filename in the Content-Disposition "header" of multipart/form-data streams does not match the other implementations I tested.

Expected Behavior

In particular, the filename \" is escaped as \%22 in curl, firefox and chrome. There is an existing discussion of this at https://github.com/curl/curl/issues/7789. actix-web should decode this as \".

Current Behavior

actix-web currently implements RFC 6266 for filename encoding and decodes this as %22, dropping the \ and not unescaping the ".

Possible Solution

Use RFC 7578 for quoted strings in the DispositionParam (un)escaping code. I am not sure if this conflicts with Content-Disposition escaping for normal HTTP-Response headers. Also, as the comment in test_from_raw_unnecessary_percent_decode states, other implementations do not percent-escape higher UTF-8 codepoints, but they do percent-escape " (and as far as i can see, only " and no other bytes).

Steps to Reproduce (for bugs)

which produces a body similar to this (not escaping the \ or ¢ and percent escaping the "):

Adapted from http::header::content_disposition::test_from_raw_unnecessary_percent_decode

Context

I am building a temporary file-uploading service, and tried uploading a file which has a " in its name, which works but writes a wrong name to the database.

Your Environment

  • Rust Version: rustc 1.59.0 (9d1b2106e 2022-02-23)
  • Actix Web Version: 4.0.1
  • curl Version: 7.82.0
  • Firefox Version: Mozilla Firefox 99.0.1
jacob-pro

jacob-pro

C-docs
1

When implementing middleware I discovered various things which seemed confusing:

When we call the underlying service self.service.call(req) it returns a result:

As far as I can tell this service call will be Ok even if the route being called returned an error:

But the service.call() can fail if another middleware in the chain fails:

E.g.

Now this leads to a bug when using the ErrorHandlers middleware:

The Broken middleware is returning a ResponseError which will cause a 500 error, but the ErrorHandler middleware returns early because it got an error when calling the underlying middleware, so it doesn't run.

Possible Solution

Please can we have better documentation for how to handle errors when writing middleware:

  1. Document when a service call can fail
  2. Document that presumably a middleware should always return a ServiceResponse or risk breaking other middlewares up the chain (e.g. ErrorHandlers, Loggers, Cors etc.)?

I do wonder if a middleware should even be allowed to return an error / if the current pattern just encourages mistakes?

See Also

https://github.com/actix/actix-extras/pull/128 https://github.com/actix/actix-web/issues/1051

Your Environment

  • Rust Version: 1.59
  • Actix Web Version: 4.0.1
jacob-pro

jacob-pro

C-improvement
2

Expected Behavior

When a route string can be matched by one (or more) route macro paths (but zero method matches) then a 405 should be returned.

Current Behavior

A 404 is returned.

Steps to Reproduce (for bugs)

Your Environment

  • Rust Version: 1.59
  • Actix Web Version: 4.0.1
allencamal

allencamal

7

Hello, and thank you very much for this crate.

Here is the gist for a reproductible example: https://gist.github.com/allencamal/cfe62dda9fc8132ba6707d5771cac7f1

Expected Behavior

It should be possible to curl the failing endpoint.

Current Behavior

When curling the failing endpoint, curl returns the following error message: curl: (18) transfer closed with 7302400 bytes remaining to read.

Possible Solution

Actually, forcing HTTP1.1 via curl with the --http1.1 option works, but I don't think this is a viable option. Disabling TLS forces HTTP1.1, and also works, but that is not something viable. Also, using spawn_blocking for the blocking sleep fixes the issue, but that does not make the bug less curious.

Steps to Reproduce (for bugs)

Gist: https://gist.github.com/allencamal/cfe62dda9fc8132ba6707d5771cac7f1

  1. Create a new cargo project
  2. Create a basic TLS server with actix-web and rustls
  3. Create an endpoint that spawns a blocking task, sleeps for 15 seconds with std::thread::sleep, and return more than 13 MB of data.
  4. Curl this endpoint. curl --insecure https://localhost:8085/failing > a

Context

Here are the two endpoints:

Here is the gist for a reproductible example: https://gist.github.com/allencamal/cfe62dda9fc8132ba6707d5771cac7f1 I'm creating a very basic HTTP web server, using TLS (so that http2 is available). I've got two endpoints, that basically just sleeps 15 secs (using std's sleep, not tokio's) and returns 20 MB of data. (for less data, e.g. 10 MB, the bug does not appears).

From my experience, sleeping for less than 15 seconds (e.g. 5 seconds) also fails, but anything less than 3 seconds works correctly.

The only difference between the two endpoints is that one calls: actix_web::rt::task::spawn_blocking(|| println!("Request will fail")).await; before sleeping (blocking).

If I curl my two endpoints:

The one that spawn a blocking task fails.

Note that on another project, I have a similar issue, but the error is curl (92) HTTP/2 stream 1 was not closed cleanly before end of the underlying stream.

Your Environment

Cargo.toml included at the beginning of the gist

  • Rust Version (I.e, output of rustc -V): rustc 1.60.0 (7737e0b5c 2022-04-04)
  • Actix Web Version: 4.0.1
robjtede

robjtede

C-improvement
0

Currently, the stream multiplexing feature of HTTP/2 is not used in the awc client. It just uses the same connection strategy as HTTP/1.1 which is wasteful on resources.

ModProg

ModProg

A-codegen
0

I posted this originally as a comment in a different issue, but I think it deserves it's own issue for discussion.

Even tho I'm a bit late to the party with the route macro already existing, but I would propose something along the lines of

If this is something you would consider, I could also implement it. This would allow defining not only multiple methods but also routes, e.g. to allow the deprecated path to still function after refactoring the API schema.

This could also be implemented in a way that keeps the current functionality in the #[route] macro.

Theoretically, the #[route] could even be dropped. But that would mean that the first macro would implicitly do the route macros job, and all lower macros are just helpers that do not actually support specification via path etc.

Originally posted by @ModProg in https://github.com/actix/actix-web/issues/1360#issuecomment-1079458839

AldaronLau

AldaronLau

good-first-issue
0

Expected Behavior

The notes at https://docs.rs/actix-web/4.0.1/actix_web/attr.get.html#notes hold true.

Current Behavior

Macro expects an Ident here

Possible Solution

Either change from Ident to to Path, or remove the note, since it's not currently true.

Steps to Reproduce (for bugs)

Simply using the syntax:

Context

I'm trying to use a guard function located within a module with actix-web's #[get] attribute macro, and can't.

Your Environment

  • Rust Version (I.e, output of rustc -V): rustc 1.59.0 (9d1b2106e 2022-02-23)
  • Actix Web Version: 4.0.1
EtienneBruines

EtienneBruines

C-bug-upstream
1

Your issue may already be reported! Please search on the Actix Web issue tracker before creating one.

Expected Behavior

After handling a request, the server should be able to handle another request.

Current Behavior

With max_connections set to 1, the server will handle one single request, and then no more.

(Note that this is with workers(1), backlog(0) and keep_alive(None))

Possible Solution

Steps to Reproduce (for bugs)

  1. Use the example code below

  2. Make one HTTP request using curl --no-keepalive -v http://localhost:8082/ (will return a 404, which is fine)

  3. Make a second HTTP request (this is where it fails)

  4. Make a third HTTP request (will also fail, but slightly different look)

Example code

Context

Your Environment

Screenshot_20220319_200353

Logs

ijackson

ijackson

C-improvement
5

Example test case

Current Behavior

Expected Behavior

The HEAD request is implemented according to the RFC specification.

I can obtain the expected behaviour by writing:

but this is not ergonomic.

Possible Solutions

  1. Make the get macro work like #[route("/foo", method="GET", method="HEAD")] (and adjust documentation accordingly). This would mean that if an application author writes the obvious code, it is also correct.

  2. Provide a new macro that behaves like #[route("/foo", method="GET", method="HEAD")], and try to discourage application authors from using #[get].

References

MDN, RFC7231 4.3.2.

Your Environment

  • Rust Version (I.e, output of rustc -V): rustc 1.61.0-nightly (1bfe40d11 2022-03-18)
  • Actix Web Version: 4.0.1
ulf5

ulf5

C-improvement
2

Hello,

I've been using actix-web for a while and it's working very well! There is one little thing that's been bothering me, though. When I write services with actix-web I really like to use the macros for specifying method and path, as in the example below:

I think it's great to have the path and method next to the implementation of the endpoint. However, nearly every time I add a new endpoint I forget to add the service to the app in when setting up the server, leading to a confused developer and a 404 when testing it out :)

I am not experienced enough with Rust's macro system to know if it's actually possible to do, but it would really be great if just using the macro could somehow add the service.

Geometrically

Geometrically

C-bug
6

Expected Behavior

In a Multipart request, as parts are received a server may validate it, check the size for maximums, and more. If an error occurs and a user need to know about it, the server can issue an "early" response, where the other parts are ignored.

Current Behavior

Actix-web returns an internal server error, closes connection, ends up with no content even though content was specified, and the worker panics with the message: thread 'actix-rt|system:0|arbiter:1' panicked at 'Multipart polled after finish'

Possible Solution

https://github.com/actix/actix-web/blob/03456b8a33a4550b94785a7612e16d715755cd00/actix-http/src/h1/dispatcher.rs#L739

This line of code on the actix web server should change. Requests should not return an error if part of the payload is dropped.

Steps to Reproduce (for bugs)

https://github.com/Geometrically/actix-web-bug-poc Run the actix server above, and request using CURL.

The expected output is: this does not show up :( However, no content is returned, and a panic is printed in the console. thread 'actix-rt|system:0|arbiter:1' panicked at 'Multipart polled after finish'

Context

My website, https://modrinth.com uses actix-web to power our open-source API (https://github.com/modrinth/labrinth). In our website, users can upload mods which have many files. We use multipart requests to do this. However, files are validated, so if an error occurs in validation it is returned early. Instead of returning the error, actix-web panics, causing the connection to close, so no error shows up to the user. Because of the panic, we cannot rollback steps in the project creation process.

Your Environment

See minimum reproducible example, barebones actix environment with actix-multipart 0.4.0

  • Rust Version: 1.59.0
  • Actix Web Version: 4.0.1/4
fbucek

fbucek

C-bug
5

With new Actix-web 4.0.x with https ( http2 ) our devices with low bandwidth connection can not download 20-30MB binary data from acitx_web server. Devices reported error like: broken pipe connection reset

When using low bandwidth connection downloading data form actix_web server fail with e.g.:

Steps to Reproduce

  1. Get actix example https://github.com/actix/examples/tree/master/https-tls/rustls and run it cargo run
  2. Copy cca 20MB file big_file into static folder
  3. run curl with rate limiter: curl --limit-rate 100k -v 'https://localhost:8443/static/big_file' --insecure > test

Note: - Without argument --limit-rate 100k -> it works as expected. - http works as expected ( just https is problem ) - devices using reqwest rust crate not curl to download data. Same result.

Context

Downloading binary data from actix-web server. ( program updates )

Your Environment

Production environment: raspberry pi ( arm ) Dev environment: macOS

  • Rust Version (I.e, output of rustc -V): rustc 1.59.0
  • Actix Web Version: 4.0.1
Tobias418

Tobias418

C-feature
1

it doesn't currently look like there is a good way to get a list of registered services/endpoints. such functionality would be useful for creating index sites that list all endpoints (my usecase).

vporton

vporton

RFC / Proposal
1

Expected Behavior

HttpServer::new should support asynchronous application factories as the argument.

Current Behavior

fails.

Possible Solution

We either add new_async method or somehow make new work for both sync and async (if possible).

Context

I tried to allocate a thread object whose allocator uses an async method. It failed and now I don't know what to do.

Your Environment

  • Rust Version: 1.58.1
  • Actix Web Version: 4.0.0-rc.1
ssokolow

ssokolow

C-feature
0

Expected Behavior

There should be a documented way to set a default handler for 4xx and 5xx errors.

Current Behavior

...which is an opportunity for bugs if the developer accidentally adds something to the list that shouldn't be there.

Possible Solution

If this isn't already concisely possible, maybe add a .default_handler function to the ErrorHandlers middleware to specify a handler that will be invoked if none of the more specific handlers match?

If it is concisely possible, Google wasn't helping and I didn't see anything relevant mentioned in the parts of the rustdocs I'm already aware of, so maybe add a link from the ErrorHandlers documentation if that's the case.

The main issue I foresee is ensuring that documentation is clear about how things are intended to work in situations like "most routes just use the default response, but one sets a custom body that should be passed through".

Context

I'm trying to ensure that all error messages that the browser might present to the user will use a template that is stylistically consistent with the 200 OK base template.

Your Environment

  • Rust Version (I.e, output of rustc -V): rustc 1.59.0 (9d1b2106e 2022-02-23)
  • Actix Web Version: 4.0.1
ssokolow

ssokolow

C-improvement
3

Expected Behavior

I should be able to use CacheDirective::Immutable for implementing Cache-Control headers for the cache-busting pattern.

Current Behavior

I have to use CacheDirective::Extension("immutable".to_owned(), None)

Possible Solution

Add CacheDirective variants for the following variants listed on MDN but missing from the enum:

  • must-understand
  • immutable
  • stale-while-revalidate
  • stale-if-error

Your Environment

  • Rust Version (I.e, output of rustc -V): rustc 1.59.0 (9d1b2106e 2022-02-23)
  • Actix Web Version: 4.0.1
jeffutter

jeffutter

C-improvement
0

Actix tasks don't show their source location in tokio-console.

Expected Behavior

I would expect to see the source location of each task in tokio console

Current Behavior

Most of the source locations appear to be from inside tokio:

Screen Shot 2022-02-10 at 12 56 08 PM

Possible Solution

It looks like this has been partially fixed in tokio: https://github.com/tokio-rs/tokio/pull/4483 but may need some additional work on the actix side as mentioned on reddit:

Note that actix-rt's spawning functions will probably also need to add #[track_caller] attributes, or else you'll just end up with a bunch of locations within actix-rt, rather than in your code. https://www.reddit.com/r/rust/comments/snt5fq/can_tokioconsole_profile_actixrt

Steps to Reproduce (for bugs)

  1. Add Console Subscriber to an actix app
  2. Launch tokio-console

Context

It is difficult to debug performance issues in async applications, such as actix-web. Most traditional profiling yields a nested async/future/tokio things but it's hard to discern where the actual bottlenecks are occurring. tokio-console is a useful tool to get better insights into async systems and it would be great if actix played nicely with it.

Your Environment

  • Rust Version: 1.57.0
  • Actix Web Version: 4.0.0-rc.1
Versions

Find the latest versions by id

http-v3.0.4 - Mar 09, 2022

Fix

  • Document on docs.rs with ws feature enabled.

http-v3.0.3 - Mar 08, 2022

Fixed

  • Allow spaces between header name and colon when parsing responses. #2684

awc-v3.0.0 - Mar 08, 2022

Dependencies

  • Updated actix-* to Tokio v1-based versions. #1813
  • Updated bytes to 1.0. #1813
  • Updated cookie to 0.16. #2555
  • Updated rand to 0.8.
  • Updated rustls to 0.20. #2414
  • Updated tokio to 1.

Added

  • trust-dns crate feature to enable trust-dns-resolver as client DNS resolver; disabled by default. #1969
  • cookies crate feature; enabled by default. [#2619]
  • compress-brotli crate feature; enabled by default. #2250
  • compress-gzip crate feature; enabled by default. #2250
  • compress-zstd crate feature; enabled by default. #2250
  • client::Connector::handshake_timeout() for customizing TLS connection handshake timeout. #2081
  • client::ConnectorService as client::Connector::finish method's return type #2081
  • client::ConnectionIo trait alias #2081
  • Client::headers() to get default mut reference of HeaderMap of client object. #2114
  • ClientResponse::timeout() for set the timeout of collecting response body. #1931
  • ClientBuilder::local_address() for binding to a local IP address for this client. #2024
  • ClientRequest::insert_header() method which allows using typed and untyped headers. #1869
  • ClientRequest::append_header() method which allows using typed and untyped headers. #1869
  • ClientBuilder::add_default_header() (and deprecate ClientBuilder::header()). #2510

Changed

  • client::Connector type now only has one generic type for actix_service::Service. #2063
  • client::error::ConnectError Resolver variant contains Box<dyn std::error::Error> type. #1905
  • client::ConnectorConfig default timeout changed to 5 seconds. #1905
  • ConnectorService type is renamed to BoxConnectorService. #2081
  • Fix http/https encoding when enabling compress feature. #2116
  • Rename TestResponse::{header => append_header, set => insert_header}. These methods now take a TryIntoHeaderPair. #2094
  • ClientBuilder::connector() method now takes Connector<T, U> type. #2008
  • Basic auth now accepts blank passwords as an empty string instead of an Option. #2050
  • Relax default timeout for Connector to 5 seconds (up from 1 second). #1905
  • *::send_json() and *::send_form() methods now receive impl Serialize. #2553
  • FrozenClientRequest::extra_header() now uses receives an impl TryIntoHeaderPair. #2553
  • Rename Connector::{ssl => openssl}(). #2503
  • ClientRequest::send_body now takes an impl MessageBody. #2546
  • Rename MessageBody => ResponseBody to avoid conflicts with MessageBody trait. #2546
  • Minimum supported Rust version (MSRV) is now 1.54.

Fixed

  • Send headers along with redirected requests. #2310
  • Improve Client instantiation efficiency when using openssl by only building connectors once. #2503
  • Remove unnecessary Unpin bounds on *::send_stream. #2553
  • impl Future for ResponseBody no longer requires the body type be Unpin. #2546
  • impl Future for JsonBody no longer requires the body type be Unpin. #2546
  • impl Stream for ClientResponse no longer requires the body type be Unpin. #2546

Removed

  • compress crate feature. #2250
  • ClientRequest::set; use ClientRequest::insert_header. #1869
  • ClientRequest::set_header; use ClientRequest::insert_header. #1869
  • ClientRequest::set_header_if_none; use ClientRequest::insert_header_if_none. #1869
  • ClientRequest::header; use ClientRequest::append_header. #1869
  • Deprecated methods on ClientRequest: if_true, if_some. #2148
  • ClientBuilder::default function #2008

Security

http-v3.0.2 - Mar 05, 2022

Fixed

  • Fix encoding camel-case header names with more than one hyphen. #2683

http-v3.0.1 - Mar 04, 2022

  • Fix panic in H1 dispatcher when pipelining is used with keep-alive. #2678

actors-v4.1.0 - Mar 02, 2022

  • Add support for actix version 0.13. #2675

web-v4.0.1 - Feb 25, 2022

Fixed

  • Use stable version in readme example.

web-v4.0.0 - Feb 25, 2022

See in-tree changelog for full list of changes since v3.x.

Changed

  • Rename test::{simple_service => status_service}. #2659

multipart-v0.4.0 - Feb 25, 2022

  • No significant changes since 0.4.0-beta.13.

http-v3.0.0 - Feb 25, 2022

See in-tree changelog for full list of changes since v2.x.

Removed

  • error::BlockingError #2660

files-v0.6.0 - Feb 25, 2022

  • No significant changes since 0.6.0-beta.16.

codegen-v4.0.0 - Feb 25, 2022

  • No significant changes since 0.5.0.

codegen-v0.5.0 - Feb 25, 2022

  • No significant changes since 0.5.0-rc.2.

actors-v4.0.0 - Feb 25, 2022

  • No significant changes since 4.0.0-beta.12.

router-v0.5.0 - Feb 22, 2022

  • No significant changes since 0.5.0-rc.3.

See full changelog in-tree →

http-v3.0.0-rc.4 - Feb 22, 2022

Fixed

test-v0.1.0-beta.13 - Feb 16, 2022

  • No significant changes since 0.1.0-beta.12.

http-v3.0.0-rc.3 - Feb 16, 2022

  • No significant changes since 3.0.0-rc.2.

http-test-v3.0.0-beta.13 - Feb 16, 2022

  • No significant changes since 3.0.0-beta.12.

awc-v3.0.0-beta.21 - Feb 16, 2022

  • No significant changes since 3.0.0-beta.20.

actors-v4.0.0-beta.12 - Feb 16, 2022

  • No significant changes since 4.0.0-beta.11.

web-v4.0.0-rc.3 - Feb 08, 2022

Changed

  • middleware::Condition gained a broader compatibility; Compat is needed in fewer cases. #2635

Added

  • Implement Responder for Vec<u8>. #2625
  • Re-export KeepAlive in http mod. #2625

http-v3.0.0-rc.2 - Feb 08, 2022

Added

  • Implement From<Vec<u8>> for Response<Vec<u8>>. #2625

Changed

  • error::DispatcherError enum is now marked #[non_exhaustive]. #2624

Fixed

  • Issue where handlers that took payload but then dropped without reading it to EOF it would cause keep-alive connections to become stuck. #2624

web-v4.0.0-rc.2 - Feb 02, 2022

Added

  • On-by-default macros feature flag to enable routing and runtime macros. #2619

Removed

  • rt::{Arbiter, ArbiterHandle} re-exports. #2619

test-v0.1.0-beta.12 - Feb 01, 2022

  • Rename TestServerConfig::{client_timeout => client_request_timeout}. #2611

router-v0.5.0-rc.3 - Feb 01, 2022

  • Remove unused ResourceInfo. #2612
  • Add RouterBuilder::push. #2612
  • Change signature of ResourceDef::capture_match_info_fn to remove user_data parameter. #2612
  • Replace Option<U> with U in Router API. #2612
  • Relax bounds on Router::recognize* and ResourceDef::capture_match_info. #2612
  • Quoter::requote now returns Option<Vec<u8>>. #2613

multipart-v0.4.0-beta.13 - Feb 01, 2022

  • No significant changes since 0.4.0-beta.12.

http-test-v3.0.0-beta.12 - Feb 01, 2022

  • No significant changes since 3.0.0-beta.11.

files-v0.6.0-beta.16 - Feb 01, 2022

  • No significant changes since 0.6.0-beta.15.

codegen-v0.5.0-rc.2 - Feb 01, 2022

  • No significant changes since 0.5.0-rc.1.

Information - Updated May 15, 2022

Stars: 14.1K
Forks: 1.4K
Issues: 130

Repositories & Extras

An fast and intuitive rust web framework

built with async/await in mind

An fast and intuitive rust web framework

Example application and boiler plate code for Rust, Actix and Heroku

Actix is a popular Rust web framework and these examples get your feet wet

Example application and boiler plate code for Rust, Actix and Heroku

Rust web application

Diesel (ORM) is used to work with the database

Rust web application

Audioserve is an audio and audio book server with a simple setup

Simple and easy to use audio and audiobook Rust web platform written in Rust

Audioserve is an audio and audio book server with a simple setup
Http

799

Rouille, a Rust web micro-framework

Rouille is a micro-web-framework library

Rouille, a Rust web micro-framework

Rust-WebSocket is a WebSocket (RFC6455) library written in Rust

Rust-WebSocket is a WebSocket (crates

Rust-WebSocket is a WebSocket (RFC6455) library written in Rust

Rust Websocket Physics Playground

A multiplayer physics playground, written in rust, using tokio-tungstenite for websockets and rapier-rs for physics

Rust Websocket Physics Playground

Rust WebAssembly A* Pathfinding Demo

This is a port of an A* implementation of mine from an old Unity maze project

Rust WebAssembly A* Pathfinding Demo

Create a ALB in AWS

Make it point to a lambda called rust-web (needed by deploy

Create a ALB in AWS

Base web app for Rust web projects

Started with the static_index example here:

Base web app for Rust web projects

Simple Rust Web Service

This is the readme file for a Medium article I published on creating a

Simple Rust Web Service

Rust Web assembly game 1024

The game logic has been developed by Rust Programming Language

Rust Web assembly game 1024
Facebook Instagram Twitter GitHub Dribbble
Privacy