Giter Site home page Giter Site logo

sergiobenitez / rocket Goto Github PK

View Code? Open in Web Editor NEW
23.2K 270.0 1.5K 7.27 MB

A web framework for Rust.

Home Page: https://rocket.rs

License: Other

Rust 99.44% Shell 0.55% HTML 0.01% Handlebars 0.01%
rocket web framework web-framework web-development rust

rocket's Introduction

Rocket

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

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: &str, age: u8) -> String {
    format!("Hello, {} year old named {}!", age, name)
}

#[launch]
fn rocket() -> _ {
    rocket::build().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 Libera.Chat at irc.libera.chat. 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
cargo run

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

Building and Testing

The core directory contains the three core libraries: lib, codegen, and http published as rocket, rocket_codegen and rocket_http, respectively. The latter two are implementations details and are reexported from rocket.

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 in all configurations. It accepts the following flags:

  • --examples: tests all examples in examples/
  • --contrib: tests each contrib library and feature individually
  • --core: tests each core/lib feature individually
  • --benchmarks: runs all benchmarks
  • --all: runs all tests in all configurations

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. Any other extra parameters are passed directly to cargo.

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 directories of respective codegen crates. 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. To update codegen test UI output, run a codegen test suite with TRYBUILD=overwrite and inspect the diff of .std* files.

API Docs

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 docs are licensed under separate terms.

rocket's People

Contributors

adrian5 avatar alanstoate avatar atouchet avatar bash avatar belst avatar blackghost1987 avatar divyahansg avatar eld avatar ianlet avatar illfygli avatar jarviscraft avatar jebrosen avatar jhpratt avatar kamilaborowska avatar kolbma avatar levkk avatar mehcode avatar messense avatar mike820324 avatar notriddle avatar sergiobenitez avatar sethlopezme avatar stuarth avatar sunng87 avatar talg avatar teiesti avatar the10thwiz avatar thoucheese avatar timando avatar yungkneez avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rocket's Issues

Resources

An idea I've been toying with is the addition of "resources" to Rocket. This would be similar to ActiveResource in Rails. The motivation is that many apps are CRUD-like, and this would remove some of boilerplate of doing this as well as provide more structure when necessary.

As an example, consider a Todo resource that be created, read, updated, and deleted. Here's what writing this might look like:

#[resource("todo")]
struct Todo {
    description: String,
    completed: bool
}

impl RocketResource for Todo {
    type ReadResponse = DBResult<Either<Template, JSON<String>>>;

    fn read(id: ID, format: ContentType) -> Self::ReadResponse {
        let todo = try!(Database::find_todo(id));
        if format.is_json() {
            Either::B(JSON(todo.to_string()))
        } else {
            Either::A(Template::render("todo", &todo))
        }
    }
}

fn main() {
    rocket::ignite().register("/", resources![Todo]).launch()
}

Note the associated type ReadResponse. This can go away entirely once impl Trait is allowed as a return type of trait methods. Then the return type can simply be impl Response.

This example above would create four routes: POST todo/, GET todo/<id>, PATCH todo/<id>, and DELETE todo/<id> mapping to the four RocketResource trait methods: create, read, update, delete. PUT should likely map to update as well, though PATCH is more appropriate. All of the RocketResource methods should have default implementation that return a "not-implemented" error of some sort. In the example above, a GET todo/<id> request would be routed to the read method, running the logic in the example. Note also the ContentType: resources will respond to any content-type, and the first content-type in the Accept header will be passed in.

Here's a sketch of what the trait might look like:

trait RocketResource {
    type CreateResponse = DefaultResponse;
    type ReadResponse = DefaultResponse;
    type UpdateResponse = DefaultResponse;
    type DeleteResponse = DefaultResponse;

    fn create(&self, format: ContentType) -> Self::CreateResponse {
        DefaultResponse::new()
    }

    fn read(id: ID, format: ContentType) -> Self::ReadResponse {
        DefaultResponse::new()
    }

    fn update(id: ID, format: ContentType) -> Self::UpdateResponse {
        DefaultResponse::new()
    }

    fn delete(id: ID, format: ContentType) -> Self::DeleteResponse {
        DefaultResponse::new()
    }
}

Of note is the create method which takes in an &self. This is because Rocket will automatically parse the incoming request from forms and JSON. This means that the resource must implement FromForm and Deserialize. An alternative is to simply pass in Data instead and let the user decide what to do. Another alternative is to pass in the accepted content-type to the resource attribute: #[resource("todo", format = "application/json, text/html")]. In this case, Rocket will return an error on any other kind of request format, and the user is guaranteed that ContentType will always be one of those in the format argument. And, the user will only have to implement FromForm if they specify text/html, and Deserialize if they specify application/json, which sounds nice.

Anyway, this is a developing thought. impl Trait in method return types would make this really nice.

The usage of the `&str` type is potentially misleading.

Steps to reproduce:

  • Have a route with the following code:

       #[derive(FromForm)]
    pub struct FormData<'a> {
        form_data: &'a str,
    }
    
    #[post("/reproduce_bug", data = "<form>")]
    fn reproduce_bug<'a>(form: Form<'a, FormData<'a>>) -> &'static str {
        assert_eq!("A value with spaces", form.get().form_data);
        "Everything is fine"
    }
  • Create a template with the following HTML, and submit it using a browser

    <form action="reproduce_bug" method="post">
        <input type="text" name="form_data" value="A value with spaces" />
        <input type="submit" value="Submit" />
    </form>

Expected behavior

The response "Everything is fine" is rendered

Actual behavior

The value of the field is "A+value+with+spaces", causing the assertion to fail and a 500 to be returned.

Additional details

This only applies to values of &str and not String, so I'm assuming that &str is unconditionally pointing at the raw request data to avoid any allocation. Even if this behavior is documented (I couldn't find it mentioned), I think this is a surprising behavior and likely to be a common source of confusion. At absolute minimum this should produce some kind of error, but even that is a sub-optimal solution as it would lead to unexpected gotchas for users who do not test their inputs with spaces.

I'd expect the framework to be allocating internally if needed to properly handle decoding entities, and pointing at the raw request data if possible. I would never expect the framework to force me to care about encoding or content-type specific details unless I've specifically asked for some form of "raw" data.

I have not checked, but I suspect there are likely similar issues if the request is submitted with a charset other than UTF-8, and for JSON requests that would require additional decoding (such as an escaped backslash character).

Stabilize HTTP library

At present, Rocket reexports Hyper types under http:hyper. Hyper causes a lot of issues, particularly when trying to optimize performance. A decision needs to be made on whether to stabilize these Hyper types, move away from Hyper (likely), or do something else all-together.

If we do move away from Hyper, here are things we should see to it that we re-implement or ensure the new library provides:

  • Automatic injection of the Date header.
  • Validation of outgoing Header names and values.

Add configuration and environments.

Unfortunately, it looks like Rocket will need (or at least benefit from) at least some configuration. Aside from the obvious address and port, Rocket also requires:

  • Logging level. (If no env variable, I suppose.)
  • Session private key.
  • Default headers, if desired.

It would be nice to split this into a separate file, too, so that changing configuration doesn't require a recompilation of the application. The file could contain a different key for each environment. Something like:

[dev]
log = debug

[stage]
address = "12.1.2.1"
port = 80
session_key = "MgbWFkZSISBVc..."

[prod]
address = "72.14.0.1"
port = 80
log = critical
session_key = "MgbWFkZSBmb3IgWW91ISBVc..."
headers = ["x-xss-protection: 1; mode=block", "x-frame-options: SAMEORIGIN"]

Each environment should have sane default. You shouldn't need a config file at all to develop.

The hello_world main function could then look like:

Rocket::mount_and_launch("/hello", routes![hello]);

Rocket would then use the environment declared in a ROCKET_ENV environment variable, or dev by default. So, for example, in production, the binary could be run as:

ROCKET_ENV=prod ./hello_world

It would be neat if Rocket checks if the binary was compiled whether the binary was compiled in release or debug mode and warn if a debug build is being used in production or if a release build is being used during development. stage should probably have no checks.

Allow streaming requests

This is necessary for several reasons:

  1. To mitigate DOS attacks.
  2. To allow file uploads without consuming massive amounts of memory.
  3. A bunch of other nice things I'm not thinking about.

Feature request: Enhance the `map!` macro to allow multiple types

Variables passed to templates often have multiple types. Creating a one-off struct for this is certainly possible, but since ultimately the map! macro is just "a hash map where the keys are strings and the values are something that can be serialized", that macro might be much more useful if the result was always HashMap<&str, json::Value>, and the macro performed the serialization eagerly.

Allow streaming responses.

Add a library response type, Stream<R: Writer> that takes an arbitrary writer and streams the written value.

Unanswered questions:
Should the bound of R be something else, such as Writer + Responder? Would that make things more or less convenient?

Test cases:
Stream a large file out.
Stream a large page out.

Website - Guide typo (Responder)

There is a typo in the guide's Responses section. There is 'Reponder' instead of 'Responder' both in the side menu and the section title.

composing routes

I'm having trouble figuring out how to compose routes. Is that possible? For example, I'd like to have a route that matches /auth that ensures the user is authenticated, and then cedes control to another route. Is that possible?

I think I can use a RequestGuard to do this, but that means that I would have to explicitly declare that on every route that starts with auth/..., which is not DRY. Is that the best way to proceed? Happy to take these questions to a gitter/slack if that's available.

Request data should exclude the `_method` parameter.

The documentation states that if the method is POST, the Content-Type is application/x-www-form-urlencoded, and the first field is called _method, the value of that field will be considered the request method instead of POST. However, the framework still includes the _method parameter in the request data, forcing the application to care that it might be there or error.

Steps to reproduce

  • Have a route with the following code:

    #[derive(FromForm)]
    struct FormData {
        form_data: String,
    }
    
    #[patch("/reproduce_bug", data = "<form_data>")]
    fn reproduce_bug(form_data: Form<FormData>) -> &'static str {
        assert_eq!("Form data", &form_data.get().form_data);
        "Everything is fine"
    }
  • Have a form with the following HTML, and submit it in the browser:

    <form method="post" action="/reproduce_bug">
      <input type="hidden" name="_method" value="patch" />
      <input type="text" name="form_data" value="Form data" />
      <input type="submit" value="Reproduce bug" />
    </form>

Expected behavior

The response "Everything is fine" is returned

Actual behavior

=> _method=patch has no matching field in struct.
=> Error: Failed to parse value from form: BadParse

Output logs are garbled when sending concurrent requests

Steps to reproduce:

  • Submit multiple concurrent requests to an application which is serving some content at /.

Expected behavior:

  • Log output is grouped per-request, or at least uses line-buffering and includes sufficient information per-line to link that line to the relevant request.

Actual behavior:

  • Logs are mixed in an unreadable fashion, such as:
GET /:
    => Matched: GET /
GET /:
    => Matched: GET /
    =>     => Outcome: Succcess
Outcome: Succcess
    => Response succeeded.
    => Response succeeded.

In particular, the => => Outcome: Succcess line seems especially undesirable.

Templates cannot be organized into subdirectories

To reproduce:

  • Create a file like templates/posts/new.html.tera
  • Have a route which performs Template::render("posts/new", &context)

Expected behavior:

The template is rendered

Actual behavior:

Error: Template 'posts/new' does not exist.

Support SSL

The most straightforward way would probably be to add a lanuch_ssl method to Rocket that takes a T: hyper::net::SslServer.

Flexible logging system

First of all, I wanna say good job. This project looks very promising.

One thing that is bugging me is how logging is set up. The way it remaps the levels from the standard debug/info/warn/error/critical to debug/normal/critical is not very intuitive and doesn't seem to be easy or allow plugging your own logger.

I think making logger pluggable and moving the current implementation to contrib would be really good. Is that something that makes sense to implement? I might give it a shot.

Implement Rocket::launch that returns Result

It should be possible for application to handle errors. For example when binding to already used port, application could decide to bind to an alternative port.

Same applies for Rocket::ignite or any other function that can panic but does not have Result alternative.

Access to remote addr and httpversion

Rocket hides some information about the request when translating hyper request data into its own. Namely remote addr and httpversion are being dropped. These items may be quite useful. Please make them available in the rocket::Request along with the other data.

bug: route function name and function parameters cannot be named identically

Example:

#[route(POST, path = "/todo", form = "<todo>")]
fn todo(todo: Todo) -> String {
    ...
}

generates...

fn rocket_route_fn_todo<'rocket>(_req: rocket::Request<'rocket>)
 -> rocket::Response<'rocket> {
    let todo: Todo =
        {
            ...
        };
    let result = todo(todo); <-----
    rocket::Response::new(result)
}

resulting in the error:

src/main.rs:1:1: 58:48 error: expected function, found Todo<'_>

Expose internal template system for improved usability

I think it would be useful if the internal template system—Handlebars or Tera—was exposed somewhere, so that it would be possible to make more template-specific modifications.

For some context, I'm using Handlebars, and I want to output a string containing HTML, however, Handlebars escapes strings by default. Hopefully this isn't a case of the XY problem, but I figure the best way I could solve this issue would be to acquire a reference to the static HANDLEBARS object, so that I could mess with the escape_fn settings or add a custom Helper.

Compile with stable Rust

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

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

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.

Automatically derive `FromFormValue` for nullary enums

Enums are very useful in structures that represents forms, particularly as parses of radio and option fields. For example, if the HTML forms contains:

<label>Select:
  <select name="select">
    <option value="a">Value A</option>
    <option value="b" selected>Value B</option>
    <option value="c">Value C</option>
  </select>
</label>

It would be nice to parse the select field as an enum:

enum SelectValue {
    A, B, C
}

In this example, "a" or "A" would parse as SelectValue::A, etc.

At present, Rocket does not support deriving FromFormValue for any types. It would be nice to extend Rocket to automatically implement FromFormValue to cover enums with nullary fields with an implementation as shown above.

Support ad-hoc query params

Something that might be nice would be to allow query string parsing without having to use a full structure. As an example, consider a simple route to some path /hello?name=Sergio. Currently, you need to write code that looks like:

struct Person {
    name: String;
}

#[get("/hello?<person>")]
fn hello(person: Person) -> ... { ... }

It's not particularly great to have to create a structure for just a single field. Instead, we could use ad-hoc query params. The example could look like:

#[get("/hello?{name}")]
fn hello(name: String) -> ... { ... }

This is much cleaner. Several params could be matched like:

#[get("/hello?{name,age}")]
fn hello(name: String, age: Option<u8>) -> ... { ... }

Don't know how to fix `static_rocket_route_info_for_` error

I tried to move routes in their own files/module for clarity and fall on a problematic routes! macro error:

error[E0425]: unresolved name `static_rocket_route_info_for_index`
  --> src/main.rs:11:33
   |
11 |     rocket::ignite().mount("/", routes![index, static_files]).launch();
   |                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unresolved name

Here is my repository gomoku-web.

Improve Logging

It's currently not possible to tap into Rocket's logging infrastructure in any easy way. Of course, logging is important, and so it's necessary to have a nice, clean API for Rocket applications to log messages. Libraries like slog and log, the latter currently used by Rocket, provide nice, structured ways to do this. Look into restructuring Rocket's logging to expose their functionalities.

The current alternative is to simply println to log.

Allow _method form field to specify HTTP verb

Browser's don't support anything but POST and GET. Still, it's nice to define an API as using the proper verb when possible. Use the well-known trick of adding a hidden form field with a known name and an http verb as a value. The field name should likely be '_method'. The value should be one of: "put", "delete", "patch".

Rocket should check for this field and use it when routing. A caveat is that Rocket may have to read the entire request to do this, which is slow and time consuming. A work around for this is to demand that _method be the first form value if it appears. Thankfully, the HTTP spec guarantees that the order in the request will match that in the form. Then, at worst, Rocket reads 8 bytes (_method=) more than it had to. Further, Rocket should only check when the request is POST of content type "application/x-www-form-urlencoded". It's unclear if "multipart/form-data" should be handled as well.

Unanswered: should this be optional? Should users be able to opt out of this feature? It seems like the upside is large and the downside is minimal, so it may make most sense to have this be a forced default.

Async story?

First, this looks extremely promising at first glance. The top level DSL looks fantastic. Nice job.

Second, do you have plans for an async version?

Just saw you used Hyper. That may answer the question.

Lack of handling for CORS/OPTIONS

In order for a server to provide an external API it needs to be able to deal with Cross Origin Resource Sharing. These are done by web browsers sending a preflight OPTIONS request asking what resources it is allowed to access on the server, then after being given a resonse containing certain information in it's header a browser will send the actual GET/PUT/POST/etc query to the server, with no response it will not do this and cause Cross Site Scripting errors to be reported.

There are two obvious ways this can be handled, the first and simplest is to add an "OPTIONS" annotation of the same ilk as the existing HTTP Methods, this will allow users of Rocket to manually implement the correct preflight request handling for api endpoints that need to provide CORS.

The other is to provide some form of automatic CORS handling, this can be seen in a number of other libraries used for web server development (outside the realm of rust) such as spring.io (http://docs.spring.io/spring/docs/current/spring-framework-reference/html/cors.html) or flasks (https://pypi.python.org/pypi/Flask-Cors).

W3 Specification on CORS: https://www.w3.org/TR/cors/

Plugin support?

Do you plan to allow for pluggable features, such as an administrator UI that could be activated by simply adding 'rocket.register_plugin'?

I am thinking about a system where users have it easy to add or remove a feature (plugin) without having too much stuff to do.

In my mind plugins would have a init method which would do all the stuff a user would normally do to glue the code.

Respect PORT environment variable

When running services in Mesosphere/Marathon cgroups, the framework sets a random number to PORT variable for the service. It would make Mesos deployments way easier if Rocket would respect the variable and override the service port with the value if set.

Would a PR to use Macros 1.1 be welcome

While most of your codegen won't be satisfied by Macros 1.1, your custom derives will be. Using libsyntax for custom derive is currently deprecated (and sounds like it's slated for removal in 1.15). Would you be open to a PR to pull the custom derives out into a separate crate which uses macros 1.1?

Website: remove cloud animation?

The website currently has a slow-moving animation of clouds in the background. It makes the browser use a lot of CPU. This in turn makes fans spin faster and generate more noise, and probably drains my laptop’s battery.

It looks nice but I didn’t even notice it at first, until I started looking for what could possibly be using so much CPU. Therefore I think not much would be lost by making the clouds static.

Dynamic segments (`<name..>`) not behaving as expected

I wrote a view like this

#[get("/sample/<path..>")]
fn stream(path: PathBuf) -> Option<NamedFile> {
    let filename = Path::new("/home/dawid/a_directory").join(path.clone());
    println!("{:?}, {:?}", filename, path);
    NamedFile::open(filename).ok()
}

I would expect path to be just the part of URL after /sample/, eg. localhost:8000/sample/dir/file.txt would make path be dir/file.txt, however, path becomes the whole URL after the hostname, in this example sample/dir/file.txt

🔧  Configured for development.
    => listening: localhost:8000
    => logging: Normal
🛰  Mounting '/':
    => GET /
    => GET /sample/<path..>
🚀  Rocket has launched from http://localhost:8000...
GET /sample/dir/file.txt:
    => Matched: GET /sample/<path..>
"/home/dawid/a_directory/sample/dir/file.txt", "sample/dir/file.txt"
    => Warning: Response was `None`.
    => Outcome: Failure
    => Warning: Responding with 404 Not Found catcher.
    => Response succeeded.

Object available to every route ad-hoc

It's not obvious how to make an object or some data available to all routes (ad-hoc). I'm thinking something like a DB connection pool object that would get passed to every route as an argument.

How would one do that with rocket?

pastebin example route not mounted

I noticed that the retrieve route is never mounted in the documentation. Everywhere is shown that you shouldn't forget to mount the new route you just made, but I missed this one. (it's not very hard to figure out by yourself but since all the others are shown I thought this one might as well be added)

Maybe it would be an idea to add it add the end of the tutorial just above the conlusion.
fn main() { rocket::ignite().mount("/", routes![index, upload, retrieve]).launch() }

I'm reffering to the pastebin example at: https://rocket.rs/guide/pastebin/

HTTP 400 is returned when it is the incorrect response code.

If deserializing the response data into a struct using FromForm fails, Rocket by default will return 400 BAD REQUEST, regardless of the reason that deserialization failed. This is the incorrect response code, unless deserialization failed due to malformed JSON. It is clearly defined in RFC 2616 as "The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.". For failures due to missing fields, unrecognized fields, fields of the wrong type, or pretty much any failure that isn't the result of the body being syntactically incorrect for the declared content-type, 422 UNPROCESSABLE ENTITY should be used instead.

Custom traits is deprecated

Running the forms example shows the following warning:

warning: `#[derive]` for custom traits is deprecated and will be removed in v1.15. Prefer using procedural macro custom derive
  --> src\main.rs:12:10
   |
12 | #[derive(FromForm)]
   |          ^^^^^^^^

Error decorator does not check error function parameters.

For example:

#[error(404)]
fn my_error() -> &str {
  "Bad page."
}

fails to compile with:

error[E0061]: this function takes 0 parameters but 2 parameters were supplied
  --> src/main.rs:1:1
   |
1  | #![feature(plugin)]
   | ^ expected 0 parameters

error: aborting due to previous error

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.