search

Spritetm / libesphttpd

NOTE: THIS CODE IS UNMAINTAINED. Please take a look at https://github.com/chmorgan/libesphttpd instead.
125 stars 109 forks source link

Adding httpdContinue, to allow asynchronously resuming a request without sending data #18

Closed spiralman closed 8 years ago

spiralman commented 8 years ago

Hopefully the change to the README makes the usage clear, but to provide a little more detail on my use-case:

I'm writing some firmware that proxies HTTP requests back to a device that uses a line-oriented TCP protocol with a persistent connection (a la Telnet). When I get an HTTP request, I need to issue a command to the other device, "pause" the HTTP connection, then resume it when I receive the response back from the other device, returning the received data.

Currently, I'm doing this by backing-up connData->conn, connData->remote_ip and connData->remote_port, then calling httpdSentCb with those values. This feels like I'm relying too much on an internal implementation detail, and it also results in an unnecessary call to httpdFindConnData.

This change just makes the resumption of a suspended connection an explicit function, and updates the sent callback to use that function. I'm not sure if there's any value in checking the send backlog when explicitly resuming like this, but it looks like it's not hurting anything, so feels like the most straightforward change.

(BTW, thanks for a great library. It's shaved many nights of work off my little toy project, and got me going quickly!)

Spritetm commented 8 years ago

Sounds mostly reasonable. I am not a fan of interrupting a http request in general, but I can see it's the easiest way sometimes. Manually merged it with my WiP, i'm working on some stuff like this anyway.

spiralman commented 8 years ago

@Spritetm thanks for taking a look and merging it in.

Out of curiosity, what would you recommend instead of interrupting the request?

FWIW, this seems very close to how most modern asynchronous web frameworks and servers (node.js/Tornado/Netty/NGINX) work. Although, they usually have an outer event loop controlling continuation, rather than relying on direct callbacks. That felt like overkill for this change, though.

Spritetm commented 8 years ago

I would say either AJAX polling or websockets, but I can imagine that's a bit overkill for a simple interface.

Spritetm commented 8 years ago

Ah, this should be in the repos already. Closing.