You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Murph McCloy (JIRA)" <ji...@apache.org> on 2009/08/27 19:22:59 UTC

[jira] Updated: (AXIS2C-1387) apache2_stream_read function ignores errors from ap_get_client_block is size_t is unsigned

     [ https://issues.apache.org/jira/browse/AXIS2C-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Murph McCloy updated AXIS2C-1387:
---------------------------------

    Attachment: apache2_stream_read_input_filter.patch

After fixing the segmentation fault, I found that using mod_deflate as an input filter does not work with axis2c.  Stepping through the code with gdb, I found that this was because of the following scenario:

1) apache2_stream_read calls ap_get_client_block from httpd's http_filters.c to get the first 3 bytes of data.
2) ap_get_client_block calls mod_deflate telling it to filter the first three bytes of the stream
3) mod_deflate process the first three bytes of the compressed payload.  This happens to produce zero output because the first three bytes of the payload doesn't produce any output bytes, so zero bytes are returned.
4) this return of zero bytes gets bubbled back up to apache2_stream_read which interprets the 0 as an end of stream.
5) the request is not served because there is no data for it due to the premature end of stream.

In order to fix this, I created a function apache2_ap_get_client_block in apache2_stream_read.  This function is practically identical to ap_get_client_block except it will loop until data at least some filtered data is produced or the end of stream is reached.  After applying this patch I was able to send compressed web service requests via httpd to axis2c.

I hope this helps and passes any tests, etc.  I would be more than happy to help getting this code moved into the source tree.  I realize very few people come across the need to compress requests, but I am sure there are some people out there that would do it, given the opportunity.

The attached patch file was created using 'svn diff' per your instructions.  It contains the fix for the segmentation fault as well as the premature end of stream error.

> apache2_stream_read function ignores errors from ap_get_client_block is size_t is unsigned
> ------------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-1387
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-1387
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: build system (Unix/Linux)
>    Affects Versions: 1.6.0
>         Environment: CentOS 5.3
> httpd-2.2.3
> rampartc-1.3.0
> dell precision desktop
>            Reporter: Murph McCloy
>            Priority: Minor
>         Attachments: apache2_stream_read_input_filter.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> This problem has only been noticed when attempting to decompress input streams via apache.
> The problem occurs when a decompression payload fails to decompress properly.  In my test case it was because the payload had some flags set in the gzip headers and mod_deflate doesn't support flags.  mod_deflate then returned an APR_EGENERAL error message.  This message then bubbled up and was returned as a -1 to apache2_stream_read.
> This is a problem because size_t, on my system, is unsigned.  The checks in apache2_stream_read fail to catch a negative value in this scenario and dont respond appropriately.
> while (count - len > 0)
> {
>     read = ap_get_client_block(stream_impl->request, (char *)buffer + len, count - len);
>     if (read > 0)
>     {
>         len += read;
>     }
>     else 
>     {
>         break;
>     }
> }
> The else statement will never get reached while read is unsigned.  Also, the while loop might have troubles as well.  I would suggest modifying read and len to be ssize_t so they match the return value of ap_get_client_block.
> If I get this modified and working, I will submit a patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.