quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MODPYTHON-255) PythonInputFilter doesn't appear to work for chunked request content.
Date Mon, 08 Jun 2009 05:16:07 GMT

    [ https://issues.apache.org/jira/browse/MODPYTHON-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717152#action_12717152
] 

Graham Dumpleton commented on MODPYTHON-255:
--------------------------------------------

William.

The content handler in this case isn't CGI it is a mod_wsgi application. Either way, it is
assumed that request content has already been dechunked and application doesn't have to worry
about it.

Now, although WSGI derives from CGI and for conforming WSGI application, like CGI, can't handle
chunked request content due to being required to not read more than CONTENT_LENGTH bytes of
request content, with CONTENT_LENGTH being taken to be 0 if not supplied, in mod_wsgi you
can step outside of the bounds if you want to and keep reading until content is exhausted.
This is intentionally allowed so can handle mutating input filters which change content length
but cant update Content-Length header, and also to handle chunked request content where there
is no Content-Length header.

So, the application in this case was quite able to handle chunked request content, at least
for case where it was dechunked by HTTP_IN input filter for it already. In this case, only
stumbled across this issue with mod_python input filter as was using it to implement a mutating
input filter that changes length of content and so test that ability of mod_wsgi for both
non chunked and chunked requests.

As to removal of chunked T-E value, can only presume you mean to delete the Transfer-Encoding
request header. For me though that might just make things harder. The presence of that header
is at the moment the only way to determine that non presence of Content-Length header can
be ignored and that content length is not in fact 0. Although, I guess I can just check for
r->read_chunked instead. Because though my reason for checking that is to do something
different in a process to which data is being proxied by custom protocol, if Transfer-Encoding
were to be deleted, then I would need to pass across separate flag to indicate this scenario.

Anyway, still think something is not right in all of this. Since wouldn't expect a problem
with HTTP_IN input filter. More likely to think it is mod_python input filter implementation
at this point, especially since it hasn't always worked for people properly before.


> PythonInputFilter doesn't appear to work for chunked request content.
> ---------------------------------------------------------------------
>
>                 Key: MODPYTHON-255
>                 URL: https://issues.apache.org/jira/browse/MODPYTHON-255
>             Project: mod_python
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.3.1
>            Reporter: Graham Dumpleton
>
> If PythonInputFilter is used to create an input filter, but content handler isn't actually
mod_python but another module which can handle chunked request content, and a request is sent
with chunked request content, then things just don't seem to work as one would expect.
> For example, if use:
> $ curl -d "abcdefghijklmnopqrstuvwxyz" http://home.dscpl.com.au/~grahamd/echo.wsgi --header
"Transfer-Encoding: chunked"
> Where the .wsgi script is for mod_wsgi and is:
> import StringIO
> def application(environ, start_response):
>     headers = []
>     headers.append(('Content-type', 'text/plain'))
>     start_response('200 OK', headers)
>     input = environ['wsgi.input']
>     output = StringIO.StringIO()
>     keys = environ.keys()
>     keys.sort()
>     for key in keys:
>         print >> output, '%s: %s' % (key, repr(environ[key]))
>     print >> output
>     length = int(environ.get('CONTENT_LENGTH', '0'))
>     #output.write(input.read(length))
>     output.write(input.read())
>     return [output.getvalue()]
> and the input filter itself is:
> from mod_python import apache
> def inputfilter(filter):
>     filter.req.log_error("inputfilter")
>     filter.req.log_error("inputfilter read()")
>     s = filter.read()
>     filter.req.log_error("inputfilter : %s" % repr(s))
>     while s:
>         filter.req.log_error("inputfilter write()")
>         filter.write(s)
>         filter.req.log_error("inputfilter read()")
>         s = filter.read()
>         filter.req.log_error("inputfilter : %s" % repr(s))
>     if s is None:
>         filter.req.log_error("inputfilter close()")
>         filter.close()
>         filter.req.log_error("inputfilter exit()")
> The curl just hangs and logged output is:
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter read()
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter : 'abcdefghijklmnopqrstuvwxyz'
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter write()
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter read()
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter read()
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter : '\\r\\n'
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter write()
> [Mon Jun 08 14:10:37 2009] [error] [client 192.168.1.5] inputfilter read()
> First off, a '\r\n' is coming from somewhere when it shouldn't and then it just blocks
on read().
> Whatever sentinel is used in input stream to indicate end of chunked request content,
it isn't being recognised by mod_python. 

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


Mime
View raw message