Forums » Development »
[Solved] Partial read of a POST'ed body with con->mode set to the plug-in ID returns unintentional 200 status
Added by AndreM2 over 4 years ago
My plug-in handles Web API requests, generates its own responses and has no physical content on disk, so all requests are handled in handle(uri_clean), using terminology from this page:
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ResponseHandling
If there is a partial POST'ed request body, then connection_handle_read_post_state returns HANDLER_WAIT_FOR_EVENT and handle(uri_clean) returns with this code.
The problem is that if the plug-in sets con->mode = p->id in handle(uri_clean), then when the rest of the POST'ed request arrives, handle(uri_clean) is not called because con->mode is no longer DIRECT and only handle(subrequest) is called unconditionally at the bottom of http_response_prepare. The default sub-request handler returns response 200.
Moving most of my request handling logic into handle(subrequest) works fine, but it appears somewhat odd to use handle(subrequest) without having handle(subrequest_start) called first, which is only called when there's a physical path.
So, the question is whether using handle(uri_clean) followed by handle(subrequest) for handling asynchronous requests is the intended way for these two handlers or there is a better approach?
Thanks
Replies (2)
RE: Partial read of a POST'ed body with con->mode set to the plug-in ID returns unintentional 200 status - Added by gstrauss over 4 years ago
lighttpd does not start processing a request with the request handlers until after it receives a complete set of HTTP request headers. However, lighttpd does not wait for the request body before starting to process the request, and that is done intentionally. The request body can arrive asynchronously, some time later.
The subrequest handler is the only place in lighttpd where you should handle the HTTP request body as that is the place designed to be called back. Other handlers are intended to adjust the request based on the HTTP request headers, and to potentially choose which subrequest handler gets to handle the request.
The naming of the handlers is historical, and well before lighttpd supported asynchronous receipt of the HTTP request body. The subrequest handler is the "handler". The "subrequest_start" is intended to be the last chance to pick a handler and do any one-time setup for the handler. The other hooks, including subrequest_start, are to manipulate or make decisions based on the HTTP request headers.
RE: Partial read of a POST'ed body with con->mode set to the plug-in ID returns unintentional 200 status - Added by AndreM2 over 4 years ago
Looks like I found the right place then. I did a bunch of tests sending request body fragments with a delay and it worked well, but I wanted to confirm this is the intended behavior. Thanks for a very detailed description.