httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Riggs <apache-li...@riggs.me>
Subject Re: svn commit: r1242351 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy.xml modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_fcgi.c server/util_script.c
Date Thu, 09 Feb 2012 16:39:38 GMT
On Feb 9, 2012, at 10:22 AM, Ruediger Pluem wrote:

> jim@apache.org wrote:
>> Author: jim
>> Date: Thu Feb  9 15:07:22 2012
>> New Revision: 1242351
>> 
>> URL: http://svn.apache.org/viewvc?rev=1242351&view=rev
>> Log:
>> Handle cases, esp when using mod_proxy_fcgi, when we do not
>> want SCRIPT_FILENAME to include the query string.
>> 
>> Modified:
>>    httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml
>>    httpd/httpd/trunk/modules/proxy/mod_proxy.c
>>    httpd/httpd/trunk/modules/proxy/mod_proxy.h
>>    httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
>>    httpd/httpd/trunk/server/util_script.c
>> 
> 
>> Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
>> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c?rev=1242351&r1=1242350&r2=1242351&view=diff
>> ==============================================================================
>> --- httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c (original)
>> +++ httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c Thu Feb  9 15:07:22 2012
>> @@ -188,7 +188,7 @@ static apr_status_t send_data(proxy_conn
>>     while (to_write) {
>>         apr_size_t n = 0;
>>         rv = apr_socket_sendv(s, vec + offset, nvec - offset, &n);
>> -        if (rv != APR_SUCCESS) {
>> +        if ((rv != APR_SUCCESS) && !APR_STATUS_IS_EAGAIN(rv)) {
>>             break;
>>         }
>>         if (n > 0) {
>> 
> 
> How is this related to the log message and the query string issue?

It appears this commit has to do with the message I sent the other day (http://mail-archives.apache.org/mod_mbox/httpd-dev/201202.mbox/%3C8EA4E5E4-F97E-410B-AAD4-257ECB4F972A@riggs.me%3E).

The question is, was that EAGAIN "fix" supposed to be included in this commit or not? Is that
even the right "fix"? That was my brute-force attempt to address the issue I was having, but
I don't know if it is correct. Do we need to check in the loop for a timeout or something
in case we keep receiving EAGAIN? Or would the timeout get picked up and bail out elsewhere?


Mime
View raw message