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-222) Support for chunked transfer encoding on request content.
Date Sat, 25 Oct 2008 10:21:44 GMT

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

Graham Dumpleton commented on MODPYTHON-222:
--------------------------------------------

This was discussed on mod_python developers list and patches still don't necessarily address
all concerns. See thread:

  http://markmail.org/message/nylwtkzz2t3nhi46

> Support for chunked transfer encoding on request content.
> ---------------------------------------------------------
>
>                 Key: MODPYTHON-222
>                 URL: https://issues.apache.org/jira/browse/MODPYTHON-222
>             Project: mod_python
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 3.3.1
>            Reporter: Graham Dumpleton
>         Attachments: mod_python-211-212-222-fix-revised.patch, requestobject.c
>
>
> It is currently not possible to use chunked transfer encoding on request content delivered
to a mod_python request handler.
> The use of chunked transfer encoding is explicitly blocked in C code by:
>         rc = ap_setup_client_block(self->request_rec, REQUEST_CHUNKED_ERROR);
> To allow chunked transfer encoding instead of REQUEST_CHUNKED_ERROR it would be necessary
to supply REQUEST_CHUNKED_DECHUNK.
> Problem is that it isn't that simple.
> First off, the problems associated with MODPYTHON-212 have to be fixed with code being
able to cope with there being no content length.
> The next issue is that req.read() method is currently documented as behaving as:
>   If the len argument is negative or omitted, reads all data given by the client.
> This means that can't have req.read() with no arguments mean give me everything that
is currently available in input buffers as everyone currently expects it to return everything
sent by client. Thus, to be able to process streaming data one would have to supply an amount
of data that one wants to read. The code for that though will always try to ensure that that
exact amount of data is read and will block if not enough and not end of input. A handler
though may not want it to block and be happy with just getting what is read and only expect
it to block if nothing currently available.
> In other words, the current specification for how req.read() behaves is incompatible
with what would be required to support chunked transfer encoding on request content.
> Not sure how this conflict can be resolved.

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