Refactor `http_loop`

Jef Roosens commented

2023-11-18 14:31:15 +01:00

Owner

The HTTP loop code is currently a bit too messy for me, so I'd like to do some refactoring.

Let steps return enum instead of boolean

An enum would better define the result of a step. It could either return "done", "io needed", or "failed", with the "failed" result signalling to the http loop that the remaining steps should be skipped (this is cleaner than having to manually set conn->state to res)

Implement uniform error handling analog to lsm
Clean up file names
Don't write headers as part of response steps

A request always needs to write the headers, so it doesn't really make sense to ask the user to do this manually. The headers could simply be written transparently before the response steps get executed.

Remove http_res body handling code

The ability to set the HTTP response body to a buf or a file isn't very flexible. I'd like to remove this code, and replace it with predefined steps that provide the same functionality.

Always parse relevant headers, in particular Content-Length

Having the user parse the Content-Length header (and others, maybe Content-Type?) with a step isn't very practical in my opinion. This parsing could be done before the request steps get executed.

Don't use LANDER_VERSION macro

The host header is automatically set to a value containing this macro. To further decouple the HTTP loop code from Lander itself, the Host header should instead be passed as an argument when creating the HTTP loop.

Move HTTP code to separate library called Lander Networking Module (lnm)

If I ever wish to use this library in other projects, I'll have to fully decouple it and move it to its own library, like lsm.

Remove arbitrary restrictions on amount of steps, headers, etc.
Allow custom headers
Stream headers

We don't really need to calculate the entire response head in advance. We could instead calculate the sizes of all the headers when adding them to the response, and write them directly to the write buffer one by one. This would save us having to allocate an additional buffer for the response.

The HTTP loop code is currently a bit too messy for me, so I'd like to do some refactoring. - [x] Let steps return enum instead of boolean An enum would better define the result of a step. It could either return "done", "io needed", or "failed", with the "failed" result signalling to the http loop that the remaining steps should be skipped (this is cleaner than having to manually set `conn->state` to res) - [x] Implement uniform error handling analog to `lsm` - [x] Clean up file names - [x] Don't write headers as part of response steps A request always needs to write the headers, so it doesn't really make sense to ask the user to do this manually. The headers could simply be written transparently before the response steps get executed. - [ ] Remove `http_res` body handling code The ability to set the HTTP response body to a buf or a file isn't very flexible. I'd like to remove this code, and replace it with predefined steps that provide the same functionality. - [x] Always parse relevant headers, in particular `Content-Length` Having the user parse the Content-Length header (and others, maybe Content-Type?) with a step isn't very practical in my opinion. This parsing could be done before the request steps get executed. - [x] Don't use `LANDER_VERSION` macro The host header is automatically set to a value containing this macro. To further decouple the HTTP loop code from Lander itself, the Host header should instead be passed as an argument when creating the HTTP loop. - [x] Move HTTP code to separate library called Lander Networking Module (`lnm`) If I ever wish to use this library in other projects, I'll have to fully decouple it and move it to its own library, like `lsm`. - [x] Remove arbitrary restrictions on amount of steps, headers, etc. - [x] Allow custom headers - [x] Stream headers We don't really need to calculate the entire response head in advance. We could instead calculate the sizes of all the headers when adding them to the response, and write them directly to the write buffer one by one. This would save us having to allocate an additional buffer for the response.