Age | Commit message (Collapse) | Author |
|
|
|
Since we don't actually need any additional context here, we can remove
it. Since that allows us to avoid calling `context()` with the
`WriteError` context selector, we can then safely rename `WriteError` to
`Write`.
|
|
Make this specifically about errors writing instead of a generic I/O
error.
Name the variant `WriteError` instead of `Write` because Snafu will
generate context selector structs with these names and we already have a
`Write` identifier imported.
|
|
If we get errors building the request or Conduit errors, respond with a
500 error. Otherwise, it's a write error, and we should do nothing
(ideally log the error), because this means the client closed the
connection or there are bigger problems.
|
|
Now that we have a `request` module, the "Request" part of the name is
redundant.
|
|
Add a new error type that we can use to collect and match errors from
`handle_request()`.
|
|
Make a separate function that can return a result to make it easier to
handle errors from the handler.
|
|
|
|
Turns out I didn't need to make it public as we only need to use it
within the module.
|
|
Want to separate request and server code.
|
|
Try making a server with more than one route.
|
|
|
|
|
|
Got a draft version of the server working.
Change the example to use the new Conduit server. Got a working HTML
fragment response.
Need to handle `conduit::Body::File` as well as unwrapped errors.
|
|
|
|
To match the struct field order.
|
|
Needed to change some things around to be able to use a mutable borrow
for the `fastcgi::Stdin` body and an immutable borrow of `request` for
all the other fields.
Passed `fastcgi::Stdin` over through a `Read` implementation, because
returning `&mut self.request.stdin()` was impossible, since the caller
owns the `fastcgi::Stdin` reference.
|
|
|
|
|
|
|
|
Seemed to make sense to add a new error type to group the parse errors
together.
|
|
|
|
|
|
Looks like we don't need to implement this hopefully.
|
|
Turns out I don't need this `'b` lifetime in the `conduit::RequestExt`
`impl`. I had just assumed it was necessary because I copied it as `'a`
from the "missing trait methods" error message.
|
|
Was getting this error about the lifetimes in the trait impl:
error[E0308]: method not compatible with trait
--> src/lib.rs:137:4
|
137 | fn host(&'a self) -> conduit::Host<'a> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime mismatch
|
= note: expected fn pointer `fn(&'a FastCgiRequest<'static>) -> conduit::Host<'a>`
found fn pointer `fn(&'a FastCgiRequest<'static>) -> conduit::Host<'a>`
note: the lifetime `'a` as defined on the method body at 137:4...
--> src/lib.rs:137:4
|
137 | fn host(&'a self) -> conduit::Host<'a> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...does not necessarily outlive the lifetime `'a` as defined on the impl at 124:6
--> src/lib.rs:124:6
|
124 | impl<'a> conduit::RequestExt for FastCgiRequest {
| ^^
error[E0308]: method not compatible with trait
--> src/lib.rs:137:4
|
137 | fn host(&'a self) -> conduit::Host<'a> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime mismatch
|
= note: expected fn pointer `fn(&'a FastCgiRequest<'static>) -> conduit::Host<'a>`
found fn pointer `fn(&'a FastCgiRequest<'static>) -> conduit::Host<'a>`
note: the lifetime `'a` as defined on the impl at 124:6...
--> src/lib.rs:124:6
|
124 | impl<'a> conduit::RequestExt for FastCgiRequest {
| ^^
note: ...does not necessarily outlive the lifetime `'a` as defined on the method body at 137:4
--> src/lib.rs:137:4
|
137 | fn host(&'a self) -> conduit::Host<'a> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Learned from these resources that the problem arose because the `impl`
uses an `'a` lifetime, but the lifetime on the `host()` method need to
be a different one:
https://github.com/rust-lang/rust/issues/56423
https://stackoverflow.com/questions/24847331/rust-lifetime-error-expected-concrete-lifetime-but-found-bound-lifetime/24848424#24848424
|
|
|
|
|
|
|
|
|
|
Trying out the Conduit API, as it seems like nice interface that I can
plug the FastCGI server into.
To do this, I need a server type, and some way to convert a
`fastcgi::Request` into a `conduit::Request`. Doing this with a new
local type that I can use to implement `conduit::RequestExt`.
|
|
Build a new `http::Request` from the `fastcgi::Request` and pass it into
the closure.
Can't move `req`, so needed to change the `from` converter to take a
reference.
Update the example code to append the `http::Request` to a file for
debugging and inspection.
|
|
So far we only added metadata and headers to the request. We also need
to include the body.
|
|
The HTTP headers from `fastcgi` come with keys in the following format:
"HTTP_USER_AGENT", "HTTP_ACCEPT_LANGUAGE".
Since most headers use an uppercase first letter of a word with hyphen
word separators, make the conversion by:
1. Removing the `HTTP_` prefix
2. Changing `_` to `-`
3. Making the first letter of each word uppercase using the Inflector
crate
|
|
Currently only converts the HTTP method and URI. Still need to convert
HTTP headers.
|
|
|
|
I want a wrapper for `fastcgi::run()` that uses `http::Request` and
`http::Response`.
Add a `lighttpd.conf` to test the FastCGI.
Print FastCGI params to give me an idea of what the request looks like.
|
|
|
|
Created with:
$ cargo init --lib
|