actix/actix-web

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

mpv945

mpv945

Comment Icon2

Microservices are very popular, and I hope to create an easy-to-use GRPC library to help developers transition to the rust ecosystem. Is there an example of integrating gRPC server and client at present? I am going to migrate dozens of projects to the excellent actix-web framework.

telezhnaya

telezhnaya

Comment Icon0

I have endpoints look like http://127.0.0.1:3050/smth1/{arg1}/smth2/{arg2}) If you want to have arg1=. and pass it through web form, the generated URL looks like curl --request GET --url http://127.0.0.1:3050/smth1/smth2/{arg2}, so it just cuts this argument. The same behaviour if I put %2E (escaped dot) as the parameter. So, I can't pass the dot as the argument through the web page at all.

jacob-pro

jacob-pro

C-feature
Comment Icon37

If you have a look on crates.io there are a proliferation of crates for doing multipart form uploads with files in actix.

Including:

I think each of these have some unique improvements and features that the others do not. It seems silly to have so many unofficial crates, and is not very friendly to people who just want to quickly get started with actix.

I am wondering if we should have an effort to consolidate all of these crates into one official one in the actix project?

rollandjb

rollandjb

Comment Icon0

Your issue may already be reported!

I have searched the issue tracker.

Expected Behavior

According to the documentation here:

[...]The Server must be awaited or spawned to start processing requests [...]

Current Behavior

It seems that spawning the server does not start the server

Possible Solution

I have insufficient rust experience to offer suggestions

Steps to Reproduce (for bugs)

This code demonstrates the problem. See context below for explanation.

  1. Add actix-web and anyhow crates to project
  2. Run with cargo run
  3. Run the command curl http://127.0.0.1:4242 in a terminal
  4. Observe the secret is received as expected
  5. Comment out line A and uncomment either of B or C
  6. Observe that the handler does not run

Context

I am trying to run a temporary http server in the background and receive information sent from a handler called on that server.

Your Environment

I am running an development in vs code on a MacBook Pro M1 Max

  • Rust Version (I.e, output of rustc -V): rustc 1.62.1 (e092d0b6b 2022-07-16)
  • Actix Web Version: 4.1.0
hirohido

hirohido

Comment Icon1

Expected Behavior

When someone makes a HttpRequest to my server, i parse the body to a struct using body: web::Json<Article> in the parentheses of the route function which works fine. But when the body of the request does not satisfy a certain field on the struct, the error message gets sent back as a response to the client.

Current Behavior

i get a response like Json deserialize error: missing field excerpt at line 6 column 1 sent back as a response to the client. This is bad because i don't want a random client to be able to know all the required fields. This is a security issue for my app. I want only an error log in the server, then to be able to handle the error without returning a 400 error response.

Steps to Reproduce (for bugs)

` #[derive(Serialize, Deserialize)]

pub struct Article { pub title: String, pub author: String, pub content: String, pub image: String, pub index: String, pub excerpt: String, }

async fn create_article(req: HttpRequest, body: web::Json) -> HttpResponse {

// some code }`

  • Rust Version : rustc 1.62.1
  • Actix Web Version: actix-web = "4"
fakeshadow

fakeshadow

Comment Icon1

Expected Behavior

actix-multipart should have limited memory usage by default.

Current Behavior

actix-multipart potentially exhaust all system memory.

Possible Solution

Apply header limit from actix-http to actix-multipart

Steps to Reproduce (for bugs)

WARNING! This example may exhaust your OS memory and please run it with caution

Context

Your Environment

  • Rust Version (I.e, output of rustc -V): nightly
  • Actix Web Version: 4.0
robjtede

robjtede

B-semver-major
Comment Icon0

Declare our MSRV in the manifest. Should be done for v5 so that folks pinning transitive deps on v4 can still use it on older compilers.

Speykious

Speykious

C-bug
Comment Icon0

Not sure how to word this title better, you might do a better job than me on that part.

While handling a Multipart payload, if we turn a field into a stream with field.into_stream and then read that stream, it can panic.

Expected Behavior

When converting the field into a stream, whether that field happens to be a file upload or a string, it would let us read the content without any problems.

Current Behavior

It can read a file upload, but panics if the multipart data is a simple string.

Possible Solution

This is the impl the panic message leads me to:

I do not know how this .unwrap() is supposed to be handled, but that's where it starts. It seems to indicate that a string value from a Multipart data does not have an inner payload.

Steps to Reproduce (for bugs)

  1. git clone the minimum reproducible code: https://github.com/Speykious/actix-multipart-bug
  2. launch request.sh
  3. observe 2 things:
  • it works perfectly fine for a file
  • it panics for the simple string with the following message:

Context

I was trying to read a file coming from a Multipart line by line using a BufRead or similar. I got to find a solution that uses an AsyncBufRead, which tokio_util's StreamReader implements. After a bit of testing, I found this bug.

Your Environment

Linux. (Given the nature of the bug, I don't think it has a major influence though.)

  • Rust Version: rustc 1.61.0 (fe5b13d68 2022-05-18)
  • Actix Web Version: 4.1.0
  • Actix Multipart Version: 0.4.0
LinusCDE

LinusCDE

Comment Icon0

Expected Behavior

Streaming responses will behave like normal responses in regards to connection limits.

Current Behavior

Running streamed responses can make other requests fail, timeout or stall.

My guess is that the streamed response somehow prevents the current worker from handling anymore requests while the response is being streamed. This shouldn't happen since the response is streamed in an async fashion.

Possible Solution

Not sure, but I would suspect some bug in how streamed responses are handled. I highly doubt that this would be intended behaviour.

I searched for the bug and didn't find any record of it. max_connections() and max_connection_rate() is already high and setting both explicitly to 100 didn't change the behaviour at all.

When enough streaming responses are stopped, new request that stalled usually also return a 408 (timed out), which seems to suggest that the request may have technically been started / timed internally to notice the timeout when handling it.

Steps to Reproduce (for bugs)

  1. Set a low amount of workers (1 or 2)
  2. Have one or 2 streamed responses running
  3. Other requests will start to take a while, timeout or stall (connected and new web sockets are also affected)

Context

Using actix-web here to download a large usb image. This download can take long and I noticed that having a download running makes other webpages (partially) unresponsive. Sometimes only websockets stopped connecting, stalled or even simple requests didn't go through as long as the download was running.

I'm using 2 workers as more makes no sense on the target platform (weak singlecore arm cpu). Increasing the amount "fixes" the problem. Running more downloads at once eventually stall the rest again though, making this an easy way to dos the server.

Your Environment

  • Rust Version (I.e, output of rustc -V): rustc 1.63.0-nightly (12cd71f4d 2022-06-01)
  • Actix Web Version: 4.0.1
  • Platform: Was running on armv7, but also does the same on x86_64 (host)

I recently migrated from an old actix 3.X to 4.0.1. I didn't notice this behaviour before, so this might be introduced in the last 2 years (or 3.X -> 4; no guarantee on this).

Below is a video demonstrating the bug manifesting:

https://user-images.githubusercontent.com/22298664/171999815-c3793d3a-17dc-4910-a432-7da9727ef237.mp4

squidpickles

squidpickles

Comment Icon2

In cases where a handler exits early without reading a supplied Payload, there is some new code in actix-web (see PR #2624) that consumes the rest of the bytes in the request.

It seems not to work with large request bodies (approaching 512k).

Expected Behavior

If a Payload is dropped before all bytes are consumed, the rest of the client request should still be consumed.

Current Behavior

If a Payload is dropped before all bytes are consumed, the rest of the request is consumed if the request is small, but larger requests stop reading and drop the connection with a message "handler did not read whole payload and dispatcher could not drain read buf; return 500 and close connection".

Possible Solution

Haven't quite found the root cause yet, but it appears that the read_buf in the Dispatcher is empty. When PayloadDecoder::decode() is called with read_buf as src, it reports zero bytes available, but self.kind contains a nonzero Kind::Length of remaining bytes. If they were both correctly zero, it would return PayloadItem::Eof, and the flush would terminate correctly. If they were both correctly nonzero, it would successfully return PayloadItem::Chunk(buf), which would continue the flush loop until exhausted.

I'm not sure which one is wrong here, but it only seems to happen if there are a certain number of reads required to flush the request.

Steps to Reproduce (for bugs)

Minimal server:

Client-side - I was able to duplicate this by sending a 511k file (succeeded), and a 512k file (failed), but managed to narrow down to exact number of bytes by using curl's -C to skip initial bytes in the file. Byte ranges may vary across OSs, not sure.

Context

I'd like to be able to return from a handler without having to worry about whether I've finished reading the Payload completely. For example, streaming a file to disk, then having a write fail, it's much easier to handle with a simple ? and a handler returning a Result, than having to wrap the whole thing in a handler that cleans up the Payload before returning an error.

Your Environment

  • MacOS 12.4 x86_64
  • actix-web 4.0.1
  • actix-http 3.0.0
  • rustc 1.61.0 (fe5b13d68 2022-05-18)
julianskartor

julianskartor

needs-investigation
Comment Icon0

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
marknijboer

marknijboer

C-bug
Comment Icon1

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).

iyzana

iyzana

needs-investigation
Comment Icon0

(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
Comment Icon1

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
Comment Icon2

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

Comment Icon7

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
Versions

Find the latest versions by id

awc-v3.0.1 - Aug 25, 2022

Changed

  • Minimum supported Rust version (MSRV) is now 1.57 due to transitive time dependency.

Fixed

  • Fixed handling of redirection requests that begin with //. #2840

test-v0.1.0 - Jul 24, 2022

  • Minimum supported Rust version (MSRV) is now 1.57 due to transitive time dependency.

http-v3.2.0 - Jul 24, 2022

Changed

  • Minimum supported Rust version (MSRV) is now 1.57 due to transitive time dependency.

Fixed

  • Websocket parser no longer throws endless overflow errors after receiving an oversized frame. #2790
  • Retain previously set Vary headers when using compression encoder. #2798

http-test-v3.0.0 - Jul 24, 2022

  • Minimum supported Rust version (MSRV) is now 1.57 due to transitive time dependency.

Full changelog since 2.1.0 →

files-v0.6.2 - Jul 23, 2022

  • Allow partial range responses for video content to start streaming sooner. #2817
  • Minimum supported Rust version (MSRV) is now 1.57 due to transitive time dependency.

http-v3.2.1 - Jul 02, 2022

Fixed

  • Fix parsing ambiguity in Transfer-Encoding and Content-Length headers for HTTP/1.0 requests. #2794

web-v4.1.0 - Jun 11, 2022

Added

  • Add ServiceRequest::extract() to make it easier to use extractors when writing middlewares. #2647
  • Add Route::wrap() to allow individual routes to use middleware. #2725
  • Add ServiceConfig::default_service(). #2338 #2743
  • Implement ResponseError for std::convert::Infallible

Changed

  • Minimum supported Rust version (MSRV) is now 1.56 due to transitive hashbrown dependency.

Fixed

  • Clear connection-level data on HttpRequest drop. #2742

http-v3.1.0 - Jun 11, 2022

Changed

  • Minimum supported Rust version (MSRV) is now 1.56 due to transitive hashbrown dependency.

Fixed

  • Revert broken fix in #2624 that caused erroneous 500 error responses. Temporarily re-introduces #2357 bug. #2779

files-v0.6.1 - Jun 11, 2022

  • Add NamedFile::{modified, metadata, content_type, content_disposition, encoding}() getters. #2021
  • Update tokio-uring dependency to 0.3.
  • Audio files now use Content-Disposition: inline instead of attachment. #2645
  • Minimum supported Rust version (MSRV) is now 1.56 due to transitive hashbrown dependency.

codegen-v4.0.1 - Jun 11, 2022

  • Fix support for guard paths in route handler macros. #2771
  • Minimum supported Rust version (MSRV) is now 1.56 due to transitive hashbrown dependency.

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.

Information - Updated Sep 01, 2022

Stars: 15.0K
Forks: 1.4K
Issues: 142

Repositories & Extras

Rust web application

Diesel (ORM) is used to work with the database

Rust web application

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

Portfolio Website in Rust w/ Rocket

This is a WIP portfolio website using Rust with the Rocket web framework, along with Postgres for the database

Portfolio Website in Rust w/ Rocket

rust-actix-react-web-starter

A bare Rust web app that uses Diesel and License

rust-actix-react-web-starter

rust-web-fullstack

Toy projects while learning rust web development

rust-web-fullstack

rust-web-services

This project implements the same API surface which was implemented in the Pluralsight course &quot;Creating Web Services with Go&quot; by Alex Schultz, with Rust using...

rust-web-services

rust-web-boilerplate

__ is distributed under the terms of the MIT License

rust-web-boilerplate

rust-web-app-example

Web App Example written in rust

rust-web-app-example

rust-web-server-wasm

compile rust source to wasm

rust-web-server-wasm
Facebook Instagram Twitter GitHub Dribbble
Privacy