A web framework for Rust.

Overview

Rocket

Build Status Rocket Homepage Current Crates.io Version Matrix: #rocket:mozilla.org IRC: #rocket on chat.freenode.net

Rocket is an async web framework for Rust with a focus on usability, security, extensibility, and speed.

#[macro_use] extern crate rocket;

#[get("/<name>/<age>")]
fn hello(name: String, age: u8) -> String {
    format!("Hello, {} year old named {}!", age, name)
}

#[launch]
fn rocket() -> rocket::Rocket {
    rocket::ignite().mount("/hello", routes![hello])
}

Visiting localhost:8000/hello/John/58, for example, will trigger the hello route resulting in the string Hello, 58 year old named John! being sent to the browser. If an <age> string was passed in that can't be parsed as a u8, the route won't get called, resulting in a 404 error.

Documentation

Rocket is extensively documented:

The official community support channels are #rocket:mozilla.org on Matrix and the bridged #rocket IRC channel on Freenode at chat.freenode.net. We recommend joining us on Matrix via Element. If your prefer IRC, you can join via the Kiwi IRC client or a client of your own.

Examples

An extensive number of examples are provided in the examples/ directory. Each example can be compiled and run with Cargo. For instance, the following sequence of commands builds and runs the Hello, world! example:

cd examples/hello_world
cargo run

You should see Hello, world! by visiting http://localhost:8000.

Building and Testing

Core and Contrib

The core directory contains the three core libraries: lib, codegen, and http. The contrib directory contains officially supported community contributions and similarly consists of lib and codegen.

Public APIs are exposed via lib packages: core/lib is distributed as the rocket crate while contrib/lib is distributed as the rocket_contrib crate. The remaining crates are implementation details.

Library Testing

Rocket's complete test suite can be run with ./scripts/test.sh from the root of the source tree. The script builds and tests all libraries and examples. It accepts the following flags:

  • --contrib: tests each contrib feature individually
  • --core: tests each core feature individually
  • --release: runs the testing suite in release mode

Additionally, a +${toolchain} flag, where ${toolchain} is a valid rustup toolchain string, can be passed as the first parameter. The flag is forwarded to cargo commands.

To test crates individually, simply run cargo test --all-features in the crate's directory.

Codegen Testing

Code generation diagnostics are tested using trybuild; tests can be found in the codegen/tests/ui-fail directory of both core and contrib. Each test is symlinked into sibling ui-fail-stable and ui-fail-nightly directories which contain the expected error output for stable and nightly compilers, respectively.

Documentation

API documentation is built with ./scripts/mk-docs.sh. The resulting assets are uploaded to api.rocket.rs.

Documentation for a released version ${x} can be found at https://api.rocket.rs/v${x} and https://rocket.rs/v${x}. For instance, the documentation for 0.4 can be found at https://api.rocket.rs/v0.4 and https://rocket.rs/v0.4. Documentation for unreleased versions in branch ${branch} be found at https://api.rocket.rs/${branch} and https://rocket.rs/${branch}. For instance, the documentation for the master branch can be found at https://api.rocket.rs/master and https://rocket.rs/master. Documentation for unreleased branches is updated periodically.

Contributing

Contributions are absolutely, positively welcome and encouraged! Contributions come in many forms. You could:

  1. Submit a feature request or bug report as an issue.
  2. Ask for improved documentation as an issue.
  3. Comment on issues that require feedback.
  4. Contribute code via pull requests.

We aim to keep Rocket's code quality at the highest level. This means that any code you contribute must be:

  • Commented: Complex and non-obvious functionality must be properly commented.
  • Documented: Public items must have doc comments with examples, if applicable.
  • Styled: Your code's style should match the existing and surrounding code style.
  • Simple: Your code should accomplish its task as simply and idiomatically as possible.
  • Tested: You must write (and pass) convincing tests for any new functionality.
  • Focused: Your code should do what it's supposed to and nothing more.

All pull requests are code reviewed and tested by the CI. Note that unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Rocket by you shall be dual licensed under the MIT License and Apache License, Version 2.0, without any additional terms or conditions.

License

Rocket is licensed under either of the following, at your option:

The Rocket website source is licensed under separate terms.

Comments
  • Compile with stable Rust

    Compile with stable Rust

    The following features need to be stabilized before Rocket can compile on stable:

    • [x] proc_macro_hygiene (rust-lang/rust#54727)
    • [x] associated_consts (rust-lang/rust#29646)
    • [x] conservative_impl_trait (rust-lang/rust#34511)
    • [x] drop_types_in_const (rust-lang/rust#33156)
    • [x] more_io_inner_methods (rust-lang/rust#41519)
    • [x] pub_restricted (rust-lang/rust#32409)
    • [x] struct_field_attributes (rust-lang/rust#41681)
    • [x] use_extern_macros (rust-lang/rust#35896)
    • [x] fn_box (rust-lang/rust#28796)
    • [x] try_from (rust-lang/rust#33417)

    The following dependencies rely on nightly features and must be updated before Rocket can compile on stable:

    • [x] pear (https://github.com/SergioBenitez/Pear/commit/333c9bf5e2c516c23b17c7482b410f1448c1b3af)

    Update (Feb 07, 2017): Added list of features used by Rocket. Update (Feb 28, 2017): Added lookup_host feature. Update (Mar 21, 2017): pub_restricted was stabilized! Update (Mar 30, 2017): Added never_type feature. Update (Apr 16, 2017): Added concat_idents feature. Update (May 19, 2017): Added struct_field_attributes and more_io_inner_methods features. Update (May 19, 2017): concat_idents is no longer used. Update (May 19, 2017): Added links to tracking issues. Update (May 20, 2017): type_ascription is no longer used. Update (Jun 19, 2017): struct_field_attributes was stabilized! Update (Jun 24, 2017): Added try_trait feature. Update (Jul 1, 2017): more_io_inner_methods was stabilized! Update (Jul 9, 2017): associated_consts was stabilized! Update (Sep 7, 2017): lookup_host is no longer used. Update (Sep 14, 2017): drop_types_in_const was stabilized! Update (Sep 14, 2017): Added decl_macro feature. Update (Mar 26, 2018): conservative_impl_trait, never_type, and i128_type were stabilized! Update (Apr 22, 2018): Added fnbox feature. Update (Apr 26, 2018): never_type stabilization was reverted (rust-lang/rust#50121). Update (May 5, 2018): Swapped macro_reexport for use_extern_macros. Update (Jul 29, 2018): Added crate_visibility_modifier and try_from features. Update (Aug 5, 2018): custom_derive is no longer used. Update (Aug 17, 2018): use_extern_macros was stabilized! Update (Sep 3, 2018): const_fn is no longer used. Update (Sep 26, 2018): Added label_break_value feature. Update (Oct 9, 2018): Removed compiler plugin features (custom_attribute, plugin). Update (Oct 9, 2018): Updated proc_macro features. Update (Mar 9, 2019): try_from was stabilized! Update (Apr 13, 2019): fnbox is no longer used. Update (Jul 9, 2019): never_type is no longer used. Update (Jul 19, 2019): decl_macro is no longer used. Update (Sep 9, 2019): specialization is no longer used. Update (Sep 10, 2019): label_break_value is no longer used. Update (Sep 18, 2019): try_trait is no longer used. Update (Sep 21, 2019): crate_visibility_modifier is no longer used. Update (May 19, 2020): proc_macro_hygiene was stabilized! Update (Jul 16, 2020): proc_macro_diagnostics is no longer used. Update (Jul 16, 2020): proc_macro_span is no longer used. Update (Jul 21, 2020): pear was updated to be stable-compatible.

    opened by SergioBenitez 118
  • Add support for listening on Unix socket

    Add support for listening on Unix socket

    TODO:

    • [x] Safely delete existing socket on startup
    • [x] Emit error when both address and port are specified(But what if I want to listen on both tcp and unix sockets?)
    • [x] TLS over unix socket

    Closes #545

    opened by messense 68
  • Tracking Issue for Async I/O migration

    Tracking Issue for Async I/O migration

    Status

    Rocket's master branch is currently fully asynchronous and supports async/await!

    Pending

    • [ ] #1067 - Remove or replace typed headers (PR: #1535)
    • [ ] #1329 - Documentation fixes, additions, improvements.
    • [ ] #1070 - Expose APIs for customizing the underlying I/O, instead of being restricted to TCP with optional TLS.
    • [ ] Detect blocking I/O in async: it seems the best we can do for now is to document the issues. A "blocking-in-async" lint in clippy or rustc would be much nicer, if feasible, but would occur upstream...someday.
    • [x] Miscellaneous small TODOs (tagged as TODO.async) throughout code.
    • [x] Response bodies are passed back to hyper using a channel.

    Done

    • [x] Async I/O everything!
    • [x] #1325 - Data reading and connection limits.
    • [x] Keep-alive and idle client timeouts
    • [x] Handling of blocking database connections.
    • [x] Gracefully handle panics with 500. (PR #1491)
    • [x] #1066 - Add a Write-like interface for responses, and consideration of AsyncRead vs Stream<Item=Result<Chunk, Error>>
    • [x] #180, #1374 - fixing graceful shutdown when using "infinite" responders
    • [x] #33 - Server-Sent Events
    • [x] #1117 - Asynchronous database pools, or at the very least forward compatibility with them.

    Design

    The async APIs are based on rust's async/await feature and std::future::Future, running on the tokio (0.2) runtime.

    • High-level APIs (routes and catchers):
      • Routes can now be defined as #[get|post|route(...)] async fn(params...) -> R where R is any Responder type. Routes that do not await anything can remain unchanged. #[catch]ers can also be defined as an async fn.
      • Methods on Data now return Futures that must be .awaited. As a consequence, any route that uses Data directly must be async. Routes that use data guards such as Json are not affected by this change.
      • Routes that make their own network requests or other I/O should be async, as it will allow other requests to continue while waiting for the operation.
    • Mid and low-level APIs (FromTransformedData and FromData, Fairing, Responder)
      • Several traits are now defined using async-trait, re-exported as #[rocket::async_trait].
      • Data is read asynchronously: DataStream implements tokio::io::AsyncRead instead of Read. Thus, FromTransformedData::transform and From(Transformed)Data::from_data are async fn or return Futures.
      • Response bodies are streamed to the client asynchronously: set_body and related methods expect tokio::io::AsyncRead instead of Read.
        • Consequently, Fairing::on_response and Responder::respond_to are now async fn. This allows Responders and Fairings to access and/or replace the body data.
    • The testing APIs have been moved to rocket::local::asynchronous and rocket::local::blocking. The blocking test API is simpler to use, and recommended when possible.
    • #[rocket::main], #[rocket::launch], and #[rocket::async_test] have been added to make async fn easily accessible for main() and test().
    • Many long-standing bugs with keep-alive, graceful shutdown (#180), performance, and more are fixed or will be easier to fix by using actively-supported versions of libraries.
    • Some new functionality will be possible to implement, such as SSE and WebSockets. These will likely not make it into Rocket 0.5. At this point, Rocket should not be missing any APIs necessary to implement SSE "by hand". WebSockets is a bit more complicated, and tracked in #90 .
    opened by jebrosen 64
  • Adopt Tracing

    Adopt Tracing

    This branch begins the process of migrating Rocket from using the log crate for diagnostics to using tracing.

    The motivation for switching from log to tracing was discussed in detail on issue #21, in particular, in this comment and later. In summary, tracing allows detailed tracking of contexts in programs, including asynchronous ones. This is essentially a structured, machine-readable form of the contexts that Rocket's current logging system conveys through indentation. Additionally, tracing data can be consumed to emit data in a wide variety of formats, and is backward-compatible with libraries that use the log crate.

    This branch begins the migration by doing the following:

    • [x] Adding a trace module with re-exports of core tracing APIs
    • [x] Adding a tracing_subscriber::Layer implementation that performs "Rocket-style" log formatting for tracing spans and events, and setting it as the default unless a tracing subscriber is set by the user
    • [x] Replacing all existing uses of the log macros with their tracing equivalents.

    Furthermore, I've begun the process of converting the existing logging to more idiomatic tracing. I've added tracing spans to several top-level scopes in Rocket, converted some log messages to structured events, and replaced some existing uses of indentation with tracing spans. Hopefully, this can serve as an example for others to continue the migration and add tracing instrumentation in new code.

    When possible, I've tried to keep the logging format as close to Rocket's existing logging. I've made a few tweaks to help communicate more of the structured data that tracing diagnostics record, but the emoji and stuff are all still there. Of course, I am open to making additional changes to the default format if desired.

    I've also re-exported some core tracing APIs to try to provide a` batteries-included experience, which seems in keeping with Rocket's philosophy. If other folks like this, we can add more re-exports; if we don't, it's fine to remove them.

    Potential future work that this PR unlocks includes:

    • [ ] Adding Rocket middleware for adding additional user-provided tracing instrumentation.
    • [ ] Adding middleware for integrating with distributed tracing using tracing-opentelemetry and trace propagation headers like b3.
    • [ ] Adding middleware for emitting [Server-Timing] headers using tracing data (similar to tide-server-timing).
    • [ ] Adding more detailed instrumentation to Rocket's internals.
    • [ ] Integrating with error handling (using tracing-error).
    • [ ] Ensuring that Rocket's code generation and tracing's #[instrument] attribute work together.

    Enjoy, and please let me know if there are any questions!

    opened by hawkw 33
  • Build error on nightly-2017-12-21

    Build error on nightly-2017-12-21

    error[E0609]: no field `lifetimes` on type `&syntax::ast::Generics`
      --> /home/sackery/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket_codegen-0.3.5/src/decorators/derive_form.rs:29:32
       |
    29 |                 match generics.lifetimes.len() {
       |                                ^^^^^^^^^
    
    error[E0609]: no field `lifetimes` on type `&syntax::ast::Generics`
      --> /home/sackery/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket_codegen-0.3.5/src/decorators/derive_form.rs:32:49
       |
    32 |                         let lifetime = generics.lifetimes[0].lifetime;
    
    nightly breakage 
    opened by ghost 30
  • FromFormField::from_data forward to from_value, or something

    FromFormField::from_data forward to from_value, or something

    Hi. I'm upgrading one of my applications from Rocket 0.4 to 0.5. I have an observation and a feature/change request regarding FromFormField.

    There are a good set of provided implementations of FromFormField. There is of course the option to implement the trait by hand. There is also the option to derive it for nested parameters. But I use newtypes heavily to make my program typesafe and clearer internally.

    Implementing FromFormField for a newtype wrapper around a small string or integer (or other similar small type) is quite inconvenient. Chiefly, the problem is the need to provide an implementation of from_data. Even if the implementation is no more than read into a string, and feed that to a string parser, the amount of boilerplate is considerable.

    Or to put it another way, there is a gap between the very cooked provided implementations, and the very manual direct impl. I think that gap consists of types which are parseable from strings (probably, smallish ones).

    I would like a more convenient way to define such a FromFormField impl. As a success criterion, it ought to make it easy to implement FromFormField for any type which is FromStr. (But not all FromStr should be FromFormField, and possibly the FromFormField might be different to the FromStr - that should be up to the type's author.)

    I have two suggestions for how to achieve this. You may have a better idea.

    1. Have the default from_data read the data to a string, and forward to from_value, rather than erroring. (Probably a smaller data limit would be a good idea.)

    2. Some kind of macro to generate a from_data impl.

    Of these I think 1 is probably best.

    To give you a flavour of what I am looking to improve, here is a fragment from in my proto-Rocket-0.5 branch right now (lightly edited, and it doesn't typecheck right now...):

    impl<'i,Id> InstanceAccess<'i,Id>
      where Id: AccessId,
            form::Error: From<Id::Error>
    {
      #[throws(form::Error<'i>)]
      fn from_str(s: &'i str) -> Self {
        /* actual code for generating an InstanceAccess from a string elided */
      }
    }
    
    impl<'v, Id> FromFormField<'v> for InstanceAccess<'v, Id>
      where Id: AccessId,
            form::Error: From<Id::Error>
    {
      fn from_value(field: ValueField<'v>) -> Result<Self, form::Error<'v>> {
        InstanceAccess::from_str(FromFormField::from_value(field)?)?
      }
    
      fn from_data<'life0, 'async_trait>(
        field: DataField<'v, 'life0>
      ) -> Pin<Box<dyn Future<Output = form::Result<'v, Self>> + Send + 'async_trait>>
      where
        'v: 'async_trait,
       'life0: 'async_trait,
        Self: 'async_trait,
      {
        InstanceAccess::from_str(FromFormField::from_data(field).await?)?
      }
    }
    
    opened by ijackson 28
  • [Feature Request] Nested form attributes

    [Feature Request] Nested form attributes

    Feature Requests

    1. Why you believe this feature is necessary.

    Go, Rails, Express all have some way of parsing nested attributes easily from forms.

    1. A convincing use-case for this feature.

    I think it would be pretty nice to have the ability to able to specify a struct like:

    #[derive(FromForm]
    struct StarterApplication {
      user: User,
      business: Business,
    }
    
    #[post("/apply", data="<form>")]
    fn post_apply(context: Context, form: StartedApplication) -> Flash<Redirect> {
      //..
    }
    

    And based on the dot notation or brackets, allow nested attributes in forms to parse automatically:

    <input type="email" name="user[email]" />
    <input type="email" name="business[name]" />
    

    or

    <input type="email" name="user.email" />
    <input type="email" name="business.name" />
    

    Instead I find myself doing this:

    #[derive(FromForm, Serialize)]
    struct StarterApplication {
        user_email: String,
        user_full_name: String,
    //... user fields ...
        business_name: String,
    //... business fields ...
    }
    

    and manually converting it to the individual structs.

    That being said, if there was a way to possibly specify multiple structs on FromForm and get access to the form field name and not just the value, that might also be a viable option? I'm not sure what my options are regardless. Perhaps I'm missing something?

    1. Why this feature can't or shouldn't exist outside of Rocket.

    It could possibly be an extension of rocket if there was a way to get the values of the fields that come through. I'm not sure that is possible though.

    Thanks!!

    request accepted 
    opened by lancecarlson 28
  • error[E0425]: cannot find value `rocket_param_id` in this scope

    error[E0425]: cannot find value `rocket_param_id` in this scope

    After updating my nightly (from 03-06) I'm getting this error, any idea how to fix it? error[E0425]: cannot find value rocket_param_id in this scope

    image

    This error happens only for my delete handler which is in a macro that's used 11 times, so I get the same error 11 times:

    			#[post("/delete/<id>")]
    			fn delete(me: Customer, id: i64) -> Res<()> {
    

    The other handlers outside of macros, and even the other handlers inside macros but with only guard args and no url args don't cause any errors. E.g. this one is also inside the same macro but causes no error:

    			#[post("/list")]
    			fn list(me: Customer) -> Res<Vec<View>> {
    
    triage deficiency 
    opened by Boscop 27
  • Clean shutdown?

    Clean shutdown?

    Is there any way to perform a "clean" shutdown of Rocket, such that any requests currently being handled can finish (and such that managed state can be cleanly dropped)? I'm assuming right now that pressing ^C just kills the program without any graceful shutdown, since I would expect Rocket to print something to stdout otherwise.

    Besides not wanting to have a bad experience for users, I'm primarily concerned with the fact that the program I'm writing is using SQLite and therefore killing it abruptly in the middle of any database mutations is probably a bad idea.

    request accepted feedback wanted 
    opened by lilyball 25
  • Add support for Range requests

    Add support for Range requests

    This is an attempt to fix #806 (at least partially).

    This transparently handles Range requests for &[u8], Vec<u8>, File and NamedFile, when the total size is known, allowing partial downloads.

    It also advertises this feature for the listed types by adding an AcceptRanges header.

    The implementation follows the MDN examples and the corresponding RFC, but only supports Single part ranges, which is compliant with the RFC, as a server may choose to ignore or reject any range request.

    Multipart ranges would most likely be better implemented as a custom Body variant and would be more complicated. I have no use case for those, which is why I did not bother, but if that would be blocking and someone can provide some directions/suggestion on how to implement those (I am not very familiar with rocket's codebase), I would try to tackle that as well. But I would strongly prefer to do that in a separate PR.

    I am looking for some initial feedback on the approach. I did implement it in the corresponding Responder implementations to have access to the Range header of the request and the response as well. It seemed fitting. But it would probably also be possible to just parse the header in the Responder and just store that in the Response or Body and deal with it later in the chain (when writing out the Response for example).

    Docs and Tests are completely lacking, also formatting was not working well, cargo fmt changed the whole codebase. So I would appreciate some more comments on what I should provide on those subjects as well.

    Thanks for your time :)

    opened by Drakulix 24
  • Static file serving

    Static file serving

    First off: let me just say that Rocket is very nice and has been a pleasure to use, kudos!

    I looked around the docs and couldn't find any support for serving a set of static files from a directory. This is something that I've seen supported in every web framework I've ever used. As an arbitrary example, here's how it works in Flask. This is a pretty common pattern to serve things like CSS files and JS scripts, so I think it would be useful to have. Obviously one can serve individual files by just having a handler that returns a File, but this seems like generally useful functionality. Ideally one would simply be able to do something like rocket::ignite().mount("/static", StaticFiles(some_path).

    question request 
    opened by luser 24
  • `url` is not passed to rusqlite anymore

    `url` is not passed to rusqlite anymore

    The SQLite database settings are passed to rusqlite via

    [default.databases.rusqlite]
    url = "file:rusqlite?mode=memory&cache=shared"
    

    in Rocket.toml according to the examples.

    However, it looks like the url is not used by rusqlite anymore since https://github.com/rusqlite/rusqlite/pull/1248. Specifically, according to the tests in that PR, Connection::open("") now has the same effect as Connection::open("file:dummy.db?mode=memory&cache=shared). In other words, the url is ignored:

        #[test]
        fn test_path() -> Result<()> {
            let tmp = tempfile::tempdir().unwrap();
            let db = Connection::open("")?;
            assert_eq!(Some(""), db.path());
            let db = Connection::open_in_memory()?;
            assert_eq!(Some(""), db.path());
            let db = Connection::open("file:dummy.db?mode=memory&cache=shared")?;
            assert_eq!(Some(""), db.path());
            let path = tmp.path().join("file.db");
            let db = Connection::open(path)?;
            assert!(db.path().map(|p| p.ends_with("file.db")).unwrap_or(false));
            Ok(())
        }
    
    triage 
    opened by rikhuijzer 1
  • "Rocket configuration extraction from provider failed." | "Rocket configuration extraction from provider failed."

    Description

    While trying to create a prototype rest api with diesel and postgresql, I've ran into this error when trying to use the ROCKET_DATABASES one-liner variable:

    Error: Rocket configuration extraction from provider failed.
       >> invalid type: string "{gaslight={url=\"postgres://introvert:5RFcGn5i45RPjSg7p7TgU56zneWiH69u@localhost/gaslight\"}}", expected a map for key `ROCKET_DATABASES` at line 2 column 18
       >> in Rocket.toml TOML file
    

    If I try to use the other variation of this databases variable, or if I use the one-liner in a normal .env file:

    Error: database config error for pool named `gaslight`
       >> missing field `url`
    Error: Rocket failed to launch due to failing fairings:
       >> 'gaslight' Database Pool
    

    To Reproduce

    Here is the github repo; gaslight.

    Environment:

    • OS Distribution and Kernel: Arch Linux 6.0.12-arch1-1
    • Rocket Version: 0.5.0-rc.2
    • Rocket Sync DB Pools Version: 0.1.0-rc.2

    Additional context

    I'm currently trying to learn how work with rust based apis using rocket, and I'm switching between documentation and an example by TmLev. And don't worry, the posgres user creds are not used on any live services.

    triage 
    opened by 1SMOL 0
  • DOCS: Create follow along tutorials like the Pastebin tutorial for all the major examples from the examples folder

    DOCS: Create follow along tutorials like the Pastebin tutorial for all the major examples from the examples folder

    Existing Functionality

    A clear and concise description of existing functionality and why it is insufficient. Examples:

    To provide some context, I've mostly been a TS/JS developer who's used Express style backend frameworks to create backend REST APIs. I'm coming to Rocket after having gone through the Rust book, solving the Rustlings course and hand type all the examples from Rust by example. So, although I'm starting to feel fairly comfortable with the Rust language in general, I'm still struggling with advanced things like lifetimes, interior mutability and reference counting as well as threading and thread safety. But being able to type out the follow along examples like the Pastebin tutorial lets me additively understand concepts and features that are gradually introduced. I believe this would be really helpful for new-ish users of the Rocket framework

    Suggested Changes

    Follow along tutorials like the Pastebin tutorial for all the major examples in the repo

    Alternatives Considered

    I've tried to type out the examples from the repo but it's quite confusing since they are not introducing a single feature/concept at a time additively to the project and hence quite difficult to trace the logical flow when faced with the entire project

    Additional Context

    I can understand that this would be a significantly large addition to the docs but I believe every example added would bring more clarity to the framework and Rust in general. This is because it would also showcase Rust's powers in a real life framework in different scenarios instead of just some synthetic examples.

    suggestion 
    opened by saikatdas0790 0
  • Make private cookies cookie marked as secure by default

    Make private cookies cookie marked as secure by default

    Existing Functionality

    Rocket is a framework using "secure defaults". However, cookies are not marked as secure by default.

    The functionality to mark a cookie as secure is there, but when libraries set cookies for you it is nearly impossible to mark it as secure. For example https://github.com/jebrosen/rocket_oauth2/blob/0.5.0-rc.1/src/lib.rs#L693 is not marked as secure and cannot be done in any trivial way.

    Suggested Changes

    Mark private cookies as secure by default. I.e. add 3 lines of code to: https://github.com/SergioBenitez/Rocket/blob/v0.5.0-rc.2/core/lib/src/cookies.rs#L497

    Alternatives Considered

    This could probably be done using some proxy like nginx, but it would be very hacky. When not using a proxy it is hard to do when using existing libraries like Rocket OAUTH2.

    Additional Context

    Options to consider:

    • only do so when a secure connection is used
    • only make it the default for production builds
    suggestion 
    opened by arjentz 4
  • Support automatic HTTP -> HTTPS redirect

    Support automatic HTTP -> HTTPS redirect

    Is your feature request motivated by a concrete problem? Please describe.

    Rocket supports TLS. It can serve TLS requests directly. Most sites that serve TLS (i.e., most sites generally 😄) will also listen on plaintext HTTP on port 80 and simply redirect to HTTPS.

    Why this feature can't or shouldn't live outside of Rocket

    HTTPS is already implemented inside of Rocket, and for good reason. One of Rust's strengths generally is simple deployment; I end up with a statically linked binary. In my case, I'm even trying to include static assets like icons and JS files inside at compile time (that feature doesn't have to live in Rocket, though!). The fact that HTTPS is a core rocket feature, but then I can't do HTTP -> HTTPS redirects easily, really limits the utility.

    Ideal Solution

    Ideally, Rocket could by default, when HTTPS is configured do what nginx does with these lines:

    server {
    	listen 80 default_server;
    	listen [::]:80 default_server;
    	server_name _;
    	return 301 https://$host$request_uri;
    }
    

    and, in addition, this could be disabled. Or vice versa (it could be optionally enabled). I think that if we're listening on port 443 for HTTPS, then it's perfectly reasonable to also listen on 80 for the purpose of redirecting to 443.

    Alternatives Considered

    I could make a second rocket (or hyper?) instance that just does this one thing, or I could bring in nginx for this one purpose. There's no documentation on having multiple rocket apps in one binary, and it seems like overkill.

    Additional Context

    Caddy does what I describe, plus it even fetches the certs for you - https://caddyserver.com/docs/automatic-https

    request 
    opened by hut8 0
Releases(v0.4.11)
Owner
Sergio Benitez
Sergio Benitez
An Extensible, Concurrent Web Framework for Rust

Iron Extensible, Concurrency Focused Web Development in Rust. Response Timer Example Note: This example works with the current iron code in this repos

null 6.1k Dec 27, 2022
An expressjs inspired web framework for Rust

nickel.rs nickel.rs is a simple and lightweight foundation for web applications written in Rust. Its API is inspired by the popular express framework

null 3k Jan 3, 2023
A web framework for Rust.

Rocket Rocket is an async web framework for Rust with a focus on usability, security, extensibility, and speed. #[macro_use] extern crate rocket; #[g

Sergio Benitez 19.5k Jan 8, 2023
A lightweight web framework built on hyper, implemented in Rust language.

Sapper Sapper, a lightweight web framework, written in Rust. Sapper focuses on ergonomic usage and rapid development. It can work with stable Rust. Sa

Daogang Tang 622 Oct 27, 2022
Web framework in Rust

Rouille, a Rust web micro-framework Rouille is a micro-web-framework library. It creates a listening socket and parses incoming HTTP requests from cli

Pierre Krieger 840 Jan 1, 2023
A fast, boilerplate free, web framework for Rust

Tower Web A web framework for Rust with a focus on removing boilerplate. API Documentation Tower Web is: Fast: Fully asynchronous, built on Tokio and

Carl Lerche 969 Dec 22, 2022
Sincere is a micro web framework for Rust(stable) based on hyper and multithreading

The project is no longer maintained! Sincere Sincere is a micro web framework for Rust(stable) based on hyper and multithreading. Style like koa. The

null 94 Oct 26, 2022
Salvo is a powerful and simplest web server framework in Rust world

Salvo is an extremely simple and powerful Rust web backend framework. Only basic Rust knowledge is required to develop backend services.

Salvo 1.2k Jan 5, 2023
The light web framework for Rust.

Rusty Web Rusty web is a simple to use, fully customizable lightweight web framework for rust developers. Learn rusty web Installation [dependencies]

Tej Magar 5 Feb 27, 2024
A flexible web framework that promotes stability, safety, security and speed.

A flexible web framework that promotes stability, safety, security and speed. Features Stability focused. All releases target stable Rust. This will n

Gotham 2.1k Jan 3, 2023
Handlebars middleware for Iron web framework

handlebars-iron Handlebars middleware for the Iron web framework. This library, together with handlebars, iron and hyper, works on both stable and nig

Ning Sun 118 Jun 28, 2022
A toy web framework inspired by gin-gonic/gin and expressjs/express.

Rum Framework A toy web framework inspired by gin-gonic/gin and expressjs/express. Installation Just add rum_framework to the dependencies of Cargo.to

Hidetomo Kou(YingZhi 2 Dec 20, 2022
JSON Web Token implementation in Rust.

Frank JWT Implementation of JSON Web Tokens in Rust. Algorithms and features supported HS256 HS384 HS512 RS256 RS384 RS512 ES256 ES384 ES512 Sign Veri

Alex Maslakov 246 Dec 27, 2022
Source Code for 'Practical Rust Web Projects' by Shing Lyu

Apress Source Code This repository accompanies Practical Rust Web Projects by Shing Lyu (Apress, 2021). Download the files as a zip using the green bu

Apress 44 Nov 17, 2022
A web application completely written in Rust. 🌍

WebApp.rs A web application completely written in Rust Target of this project is to write a complete web application including backend and frontend wi

Sascha Grunert 2.1k Dec 30, 2022
Web Server made with Rust - for learning purposes

Web Server made with Rust - for learning purposes

Lílian 2 Apr 25, 2022
Archibald is my attempt at learning Rust and writing a HTTP 1.1 web server.

Archibald To be a butler, is to be able to maintain an even-temper, at all times. One must have exceptional personal hygiene and look sharp and profes

Daniel Cuthbert 4 Jun 20, 2022
VRS is a simple, minimal, free and open source static web server written in Rust

VRS is a simple, minimal, free and open source static web server written in Rust which uses absolutely no dependencies and revolves around Rust's std::net built-in utility.

null 36 Nov 8, 2022
Example Blog using Rust, Actix Web, HTMX, Mustache

Actix Blog An example blog built with Actix. It uses htmx and handlebar templates. Running To run the blog, you need to have a recent version of Rust

Dru Jensen 2 Nov 11, 2022