# Apparent deadlock with fastcgi

**URL:** <https://www.ruby-forum.com/t/apparent-deadlock-with-fastcgi/223611>\
**Category:** NGINX\
**Created:** [October 11, 2012, 12:19am UTC](https://www.ruby-forum.com/t/apparent-deadlock-with-fastcgi/223611 "2012-10-11T00:19:22Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\
**Post date:** [October 11, 2012, 12:19am UTC](https://www.ruby-forum.com/t/apparent-deadlock-with-fastcgi/223611/1 "2012-10-11T00:19:22Z")

</div>

I have a simple fastcgi responder that converts a JSON post to a CSV  
download. It works in a streaming fashion, writing the response before  
finishing reading the request. According to the FastCGI specification,  
such  
operation is allowed:

[http://www.fastcgi.com/devkit/doc/fcgi-spec.html](http://www.fastcgi.com/devkit/doc/fcgi-spec.html)

“The Responder application sends CGI/1.1 stdout data to the Web server  
over  
FCGI\_STDOUT, and CGI/1.1 stderr data over FCGI\_STDERR. The application  
sends  
these concurrently, not one after the other. The application must wait  
to  
finish reading FCGI\_PARAMS before it begins writing FCGI\_STDOUT and  
FCGI\_STDERR, but it needn’t finish reading from FCGI\_STDIN before it  
begins  
writing these two streams.”

Using a debugger I observe that my responder blocks while reading from  
FCGI\_STDIN before I have received the whole request, which I think  
implies  
there is a bug on the nginx side.

If I buffer the entire response in memory before sending it to back to  
nginx, I don’t see the problem with the blocking read on the request.

I only observe this problem when the request is “large enough”, but I’m  
not  
sure what exact size triggers the problem.

Does nginx support this sort of behavior for fastcgi responders? If not,  
is  
that fact documented somewhere that I missed?

Posted at Nginx Forum:

> **[apparent deadlock with fastcgi](https://forum.nginx.org/read.php?2,231607,231607#msg-231607)**
>
> I have a simple fastcgi responder that converts a JSON post to a CSV download. It works in a streaming fashion, writing the response before finishing reading the request. According to the FastCGI specification, such operation is allowed:...

---

<div class="post-metadata">

**Author:** ![jkl](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/5e9695/32.png) [@jkl](https://www.ruby-forum.com/u/jkl)\
**Post date:** [October 11, 2012, 12:49am UTC](https://www.ruby-forum.com/t/apparent-deadlock-with-fastcgi/223611/2 "2012-10-11T00:49:09Z")

</div>

Hello!

On Wed, Oct 10, 2012 at 06:18:59PM -0400, jkl wrote:

> finish reading FCGI\_PARAMS before it begins writing FCGI\_STDOUT and  
> I only observe this problem when the request is “large enough”, but I’m not  
> sure what exact size triggers the problem.
> 
> Does nginx support this sort of behavior for fastcgi responders? If not, is  
> that fact documented somewhere that I missed?

It’s not supported. As long as nginx sees full response headers -  
it considers rest of request body unneeded and stops sending it.

–  
Maxim D.

> **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)**
>
> Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises.