[
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.
