It's still in development, but this may turn out better: https://github.com/iron/iron

Maybe so, but jesus christ, is it some kind of rule that every framework needs to invent its own cutesy-poo vocabulary loosely related to its name? If "ingots" are just middleware, just say middleware. And WTF is a Furnace? I see there's also "Alloy".

And also:

    server.smelt(JSON::new());

At least they're consistently hip!

Floors author here. I'm glad to see other folks jumping on that train beside me :)

Iron looks smart and I might steal some ideas or code along the way. I come in peace :)

Glad to have company :) Drop us a line, we'd love to talk shop.

This

    request.params.get(&"userid".to_string()).as_slice()

is rather ugly in comparison with Express's `req.params.userid` (or Sinatra's `params[:userid]`). Can something nicer be done here?

Yeah, this cracks me up, too. I'm still learning the basics of Rust and so there is a high chance that it's just me being stupid. Strings are not just Strings in Rust land so there was plenty of room for me to fail :)

I created a ticket to check all usage of Strings in the entire code base. You might want to track it for further progress on that.

https://github.com/cburgdorf/Floor/issues/12

At any given moment, there will exist at least one feature of Rust that is suffering temporary workarounds as a result of flux in the implementation. Strings are such a feature at the moment, and ugly code like the above is the interim solution. It will look nicer for 1.0. :)

Great: I wasn't sure if it was a feature of the framework or the language! Like many others here, I'm looking forward to playing with Rust in earnest once it's a little more mature.

Cool. Question though, can Floor serve HTTPS requests? Can it make requests to SSL protected API resources or make a TCP connection with SSL? Is that part of the API or easy to do? If so I'll give this a try. Thanks for making this.

Edit:

I don't think it does let you serve HTTPS requests:

https://github.com/cburgdorf/Floor/blob/548916fe7e4cbdc67eed...

One could SSL terminate with nginx though, but the problem of easy SSL in Rust persists.

rust-http supports SSL on the client side but does not on the server side. I am inclined to think this a good idea for the moment, as it is a high-risk area; for that matter, I do not recommend that people have rust-http servers directly facing the Internet for the moment, as there may be DoS attack vectors in it. I recommend sitting it behind a reverse proxy for the moment, such as nginx. For SSL support, I would recommend using something like nginx or stunnel. (This is a security improvement also in case of things like Heartbleed, as the server with most of the sensitive data is in an isolated process.)

Eventually rust-http (or rather, Teepee) will be capable of doing all these things itself, but for the moment—be cautious. For that matter, I don’t recommend that people write web things in Rust yet.

I really think that should be left to nginx or stud or something like that. It's the Unix way, with which I mean, it's less likely someone's going to fuck something up.

Floors author here. I'm glad Chris Morgan answered already because there isn't much I could have told you about that. I'm relying on all the great groundwork Chris already put into rust-http. Keep an eye on http://teepee.rs/. It will soon become the more advanced replacement of rust-http.

teepee looks awesome! Thanks.

It's nice to see so much activity around Rust. On the other hand, the frameworks I've seen seem to all suffer from the same issue: they seem to be intended for very simple use cases. How do you plugin an authentication middleware? How do you do resource traversal?

Floors author here. It's great to have people like you commenting on such things so that other people like me get ideas for things to hack on :)

That said, I'm still learning the basics of Rust and therefore try to narrow the scope. Floor strives for simplicity rather than being feature rich. When I turned to Rust I was disappointed to see what the state of web development was. It seemed to be extremely complicated to even write a very simple web server. Especially compared to how easy such things are with something like express.js.

Rust is still under heavy development but I think we will see a lot of those missing bits popping out here and there in the coming months.

Probably because they are the first tries in an environment where even the language is rapidly moving. I don't expect any of them to survive in that form once Rust 1.0 is out (my Sinatra clone certainly didn't).

I just added a basic middleware system to Floor. Pretty much similar to what expressjs uses.

http://cburgdorf.github.io/Floor/doc/floor/struct.Floor.html...

Barely educated guess, Rust has closures and Floor routes looks like Flask. Flask uses python decorator (closure wrapping) to provide 'middlewares'.

Can somebody shed a light on what the ''a means in the Request type?

  pub struct Request<''a> {
      pub origin: &''a Request,
      pub params: HashMap<String, String>, 
  }

The doubled ' is just a bug in the documentation generator (fixed by https://github.com/mozilla/rust/pull/14900, which is unfortunately (and strangely) failing tests at the moment).

Its true form is

   pub struct Request<'a> {
       pub origin: &'a Request,
       pub params: HashMap<String, String>
   }

where the 'a is representing the lifetime of the origin reference (that is, it is asserting that a Request struct is only usable for as long as the reference in the `origin` field is valid). Lifetimes/references are one of the core features of Rust guaranteeing both memory safety and performance.

See also: http://doc.rust-lang.org/master/guide-lifetimes.html

(Sorry, I misspoke, #14900 is fixing a different rustdoc issue: the fix for '' is https://github.com/mozilla/rust/pull/14906 .)

Looks like it's supposed to be a lifetime name, but it got munged in the docs:

https://github.com/cburgdorf/Floor/blob/master/src/request.r...

If you're unfamiliar, Rust has some fairly strict rules about lifetimes. Basically this syntax means that the thing referenced by `origin` needs to live for as long as the Request that contains it.

It means that the `origin` will be safely usable for as long as the `Request` structure owning it is alive.

In rust "lifetime" can be a part of the type, so Rust compiler can ensure that no code can keep reference to `origin` for longer than it keeps reference to the structure that owns it.

I think the point to be made here is that the Request type of origin is an http.Request, not a request.Request, so this isn't an insane recursive structure.

What it means is the local request.Request object Floor passes to handlers takes an exclusive immutable borrow of the incoming http.Request object; the 'a is effectively just house keeping to make the compiler happy, because we know the http.Request, coming from a higher call will always exist for the lifetime of the request.Request object in the handler.

...so what you said is true, but the point is that we're asserting using prior knowledge that the compiler cant infer about the lifetime of that borrowed http.Request object.

At least, thats my take on it.