ivmarkov / edge-net

async + no_std + no-alloc implementations of various network protocols
Apache License 2.0
88 stars 15 forks source link

HTTP Server Write Timeout #26

Open DaneSlattery opened 3 days ago

DaneSlattery commented 3 days ago

Is it possible for a handler to be stuck during the write_all phase of a response? Take the code below, if conn.write_all was writing a large buffer or over a slow connection, and the client closed the connection.

Would the handler be stuck trying to write_all forever?

impl<'b, T, const N: usize> Handler<'b, T, N> for HttpHandler
where
    T: Read + Write,
    T::Error: Send + Sync + std::error::Error + 'static,
{
    type Error = anyhow::Error;

    async fn handle(&self, conn: &mut Connection<'b, T, N>) -> Result<(), Self::Error> {
        let headers = conn.headers()?;

        if !matches!(headers.method, Some(Method::Get)) {
            conn.initiate_response(405, Some("Method Not Allowed"), &[])
                .await?;
        } else if !matches!(headers.path, Some("/")) {
            conn.initiate_response(404, Some("Not Found"), &[]).await?;
        } else {
            conn.initiate_response(200, Some("OK"), &[("Content-Type", "text/plain")])
                .await?;

            conn.write_all(b"Hello world!").await?;
        }

        Ok(())
    }
}
ivmarkov commented 3 days ago

I think if the client closed the write pipe (read pipe, from the client POV) you should get an error...

Do you experience this?

DaneSlattery commented 3 days ago

I am trying to drill down into it. I seem to be experiencing something like this where the http server begins to refuse connections.

The remaining services seem to continue working (mqtt, modbus, uart , WiFi etc) , but http goes dark. It’s kind of hard to replicate, and I’ve only noticed it after coming back to an esp32 that’s been running for a few days