Re: RAW POST DATA

Andrei Zmievski wrote:

On Tue, 12 Nov 2002, Hartmut Holzgraefe wrote:

the current problem with HTTP_RAW_POST_DATA is just that i never really figured out when it should be populated depending on HTTP method, Content type and always_populate_raw_post_data, this is going to be fixed today

Okay.

HTTP_RAW_POST_DATA now behaves exactly like with 4.2:

                                always...off    ...on   php://input
POST without content type            yes          yes       yes
POST with default FORM type          no           yes       yes
POST with multipart FORM type        no           no*       no**
POST with unknown content type       yes          yes       yes
PUT and other methods                no           no        yes

* This is different as in 4.0/4.1 due to the new streaming rfc1867 handler. ** would be possible to implement without wasting memory, but not in time for 4.3

besides the HTTP_RAW_POST_DATA issue what i did was a cleanup of the HTTP content handler code in SAPI.c that fixes problems with PHP not comsuming content data although at least the apache 1.x API relies on it (for keepalive connections)

That needs to be tested pretty well, I imagine?

works for me ;) (and CGI testing - needed for POST tests - is still broken :o ) i didn't touch the actual post data parsing, just cleaned up the interface between SAPIs and PHP post handlers the cleanup for keepalive is just a loop in the request shutdown part that calls the SAPIs read_post handler until no further data is returned by that regarding run-tests.php and CGI i have a patch that makes php-cgi accept command line parameters (as needed for ini settings and stuff in run-tests.php) even if it detects a CGI environment setup (which makes it ignore argc/argv switches like -q, -f and -d right now) if the USER_AGENT is set to "run-tests.php" i have also added an --ENV-- section for .phpt files so that it is possible to set things like CONTENT_TYPE, REQUEST_METHOD and others, this i needed for WebDAV tests ... but this is another story ...

php://input works for the apache sapi, but not with CGI i had no time yet to realy dig into it but i'm pretty sure it is a problem within the CGI sapi code and not in the content handler ... i definetly want this feature in 4.3 as with plain 4.2.x it is impossible to handle PUT and WebDAV requests and even with the allow_webdav_methods patch and HTTP_RAW_POST_DATA extended to PUT and WebDAV specific methods you get back the same memory consumption problems as with file uploads before 4.2.0

This php://input thing is what concerns me. How much time do you need to finish and test it? We don't want to delay RC1 too much.

it is finished (it is just a simple stream that interfaces to the SAPI read_post handler if content had not been parsed by some PHP post handler. if a post handler had been used and the data it read is still available in SG(request_info) it delivers this from memory instead, and if the post data is no longer available as with the rfc1867 multipart/form-data handler it returns EOF right away i already use this for webdav instead of HTTP_RAW_POST_DATA without problems and have figured out what made CGI fail yesterday, so now it works for me with both apache 1.x and cgi sapi. as all it relies on is the current SAPIs read_post handler it should be working with all other SAPIs as well as long as read_post is defined and working in that SAPI, and with SAPIs that don't provie read_post (like CLI) it is just a no-op -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: hartmut@six.de Tel.: +49-711-99091-77