How to abort subrequest properly?

[Marcus Clyne]

El 04/07/13 02:43, Yichun Zhang (agentzh) escribió:
> Hello!
>
> On Wed, Jul 3, 2013 at 5:37 PM, Marcus Clyne wrote:
>>> If the subrequest uses the upstream mechanism, wouldn't it be safe to just
>>> close the socket of upstream's connection?  I'm assuming there would be an
>>> entry in the error log, but is there anything harmful that could come from
>>> it?
>>>
>> And you'd obviously want to finalize the subrequest, probably do something
>> like ngx_http_finalize_request(sr, NGX_OK).  I don't think you could just
>> issue this on its own, since I think the subrequest's sockets wouldn't
>> automatically be closed until the main request was finalized (but it's been
>> a while since I've done core hacking, and I can't remember for sure).
>>
> No. For modules based on ngx_http_upstream, the right way to shut it
> down is to call ngx_http_upstream_finalize_request. This is exactly
> what the cleanup handler registered by ngx_http_upstream does (i.e.,
> the gx_http_upstream_cleanup function). And that's why I propose the
> solution of calling the cleanup handler on the subrequest.
>
> Calling ngx_http_finalize_request(sr, NGX_OK) does not really help
> here because the subrequest's cleanup handler that actually shuts down
> the upstream socket (and other resources like the resolver) will not
> be triggered until the main request is cleaned up.
Hence why I was suggesting closing the socket as well as calling 
ngx_http_finalize_request.  I think the only thing you really need in 
the time before the main request finishing is that you don't get any 
data on the socket, and your request count is correct.  The upstream 
request obviously needs to be closed properly, but if the upstream 
cleanup function is going to be called anyway by the main request, then 
I'm not sure it really makes any difference, and you'd be running 
through the cleanup function twice.
>
> On the other hand, calling ngx_http_upstream_finalize_request directly
> on the subrequest should work for strict upstream modules but this is
> just too specific and hacky to be really interesting for any descent
> 3rd-party modules :)
Hacky, for sure but it sounds like this is a custom setup anyway. This 
is obviously only going to be useful if the body is one that uses 
upstream requests.

Marcus.