#23 Handle HEAD requests #31
Conversation
|
Thanks @DeltaManiac! So, the goal with #27 is to be able to write a |
|
Ok, then this is definitely not going to work, thanks for the clarification |
|
HI @aturon I've made some changes to automatically fallback to the GET implementation if there is not specialized implementation for HEAD while still allowing users to override this behavior if necessary. Please let me know if this is ok or there are anymore changes you'd like |
|
This is heading in the right direction! But can you pull out the call to |
|
Done |
src/router.rs
Outdated
| self.table | ||
| .route(path) | ||
| .and_then(|(r, p)| Some((r.endpoints.get(method)?, p))) | ||
| let route = self.table.route(path).unwrap(); |
There was a problem hiding this comment.
This unwrap will panic if the route isn't found. You should be able to replace it with route(path)?
There was a problem hiding this comment.
Done!
Sorry about overlooking that the first time around :)
src/router.rs
Outdated
| self.table | ||
| .route(path) | ||
| .and_then(|(r, p)| Some((r.endpoints.get(method)?, p))) | ||
| let route = self.table.route(path)?; |
There was a problem hiding this comment.
Maybe do something like let (route, route_match) = self.table.route(path)?; here? (I am not sure what could be the best names here though)
Then later you don't have to use route.0 and route.1 below?
There was a problem hiding this comment.
Agreed, that'd be a nice code cleanup. Other than that, looks good to go!
There was a problem hiding this comment.
I agree this enhances readability and I've done the changes,
Just for a personal learning, is using the tuple.0,tuple.1 syntax generally avoided?
There was a problem hiding this comment.
I am new to Rust as well, might not have the best opinion here but I simply find tuple.0, tuple.1 difficult to read as they look like the tuple type but it could be completely a different type. Just from tuple.0 I don't know the name of it and I don't know the type of it, without looking for the definition of tuple somewhere else. I guess if you use them only once or twice and they are very close to where tuple is defined/created, then maybe it is fine. Especially if you only have one element in the tuple (like a wrap of some other type) then using tuple.0 around is probably okay. Otherwise give them names might help a bit in most cases. Just my opinion :P
|
Merged, thanks for the contribution! |
@aturon
Have I missed something crucial here?
Analyzing with wireshark I do observe that there is no body being sent in the response just the headers when triggering a HEAD invocation