-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This page can be used for hacking the design/spec together until it can be moved to a .md file in the repo
Missing features:
- serving anything but HTML, JPEG or static files.
- A templating system that prevents escaping errors in the response.
- HTTP redirects.
- Serving pages with radically different request parameters, deserving of different
Paramstypes. -
handle_post().
Present features:
- A system that prevents escaping errors in the request.
- Rust's ? operator generates HTTP error responses.
- You never see a
Url. - Useful utilities for manipulating and testing parts of URL paths.
Informal criterion is "anything needed by Ocularity, photo server, Nifki, questionnaire, congenialwiki". It's far from a feature-complete web app framework, as it should be. Just the 80% functionality.
Serving pages with radically different request parameters, deserving of different Params types.
For this, I think a possible design is a dispatch() function that picks a Handle implementation and passes it to a callback.
Then different URL paths can have different Params types, and each be statically type checked.
- A templating system that prevents escaping errors in the response. For this the minimum viable product is a trait ToHtml with three implementations:
- &'static str (no escaping)
- struct User(String) (HTML escaping)
- struct Url(String) (%-encoding then HTML escaping)
I'm thinking that HttpOkay::Html payload should be a Box, i.e. the handler can return a ToHtml for this particular case, and petite_http will escape it correctly.
If use a templating engine such as ramhorns, it will generate correctly escaped HTML. To avoid escaping it a second time, return it as Http::Text(..., content_types::HTML) just like any other text-based file type. HttpOkay::Html(...) is only intended for apps that want to generate their own HTML correctly.
let's not go down the npm route of oneliner dependencies; but equally, let's continue to use url::Url which appears to have already gone down that route... (I looked for viable alternatives and there aren't any.)
- https://docs.rs/crate/idna_adapter/latest seems relevant.
- Have a think about how you want to do testing and publishing to crates.io.
- We should probably have an example web app that you can
cargo runin the petite_http crate. - yeah it should be done properly; i mean we can get it working for our use cases, but committing to a good v1.0 down the line