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: [EMAIL PROTECTED]
Tel.: +49-711-99091-77
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
