Zitat von Hartmut Holzgraefe <[EMAIL PROTECTED]>:
> Hartmut Holzgraefe wrote:
> > Jan Schneider wrote:
> >
> >> To resume: best practice is currently to use $HTTP_RAW_POST_DATA if
> >> available and php://input else. And crossing fingers that either of
> them
> >> works, of course. ;-)
> >
> >
> >
Markus Fischer wrote:
If I just want to see the RAW data it's still easier to do
var_dump($HTTP_RAW_POST_DATA);
than anything else to me.
now you can do
readfile("php://input");
this has the following advantages:
- less typing, saves you 6 keystrokes ;)
- does not only wor
On Wed, Nov 13, 2002 at 10:27:09AM +0100, Hartmut Holzgraefe wrote :
> Hartmut Holzgraefe wrote:
> >Jan Schneider wrote:
> >
> >>To resume: best practice is currently to use $HTTP_RAW_POST_DATA if
> >>available and php://input else. And crossing fingers that either of them
> >>works, of course. ;-
Could you apply --ENV-- patch then or send a patch?
I thought about this myself but didn't had time to do
it myself yet. If we had this we could test the behaviour
of some superglobals with all related ini settings.
marcus
At 10:25 13.11.2002, Hartmut Holzgraefe wrote:
Andrei Zmievski wrote:
On
Hartmut Holzgraefe wrote:
Jan Schneider wrote:
To resume: best practice is currently to use $HTTP_RAW_POST_DATA if
available and php://input else. And crossing fingers that either of them
works, of course. ;-)
hmyes, but it *should* be to use php://input and forget
about $HTTP_RAW_POST_DATA a
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.
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.
> besides the HT
Andrei Zmievski wrote:
How much is this going to delay 4.3.0? I'm just a bit wary of changing
such an essential part of PHP interaction (with server and users) before
a big release..
the current problem with HTTP_RAW_POST_DATA is just that
i never really figured out when it should be populated
d
Zitat von Hartmut Holzgraefe <[EMAIL PROTECTED]>:
> Jan Schneider wrote:
> > To resume: best practice is currently to use $HTTP_RAW_POST_DATA if
> > available and php://input else. And crossing fingers that either of
> them
> > works, of course. ;-)
>
> hmyes, but it *should* be to use php://inpu
Jan Schneider wrote:
To resume: best practice is currently to use $HTTP_RAW_POST_DATA if
available and php://input else. And crossing fingers that either of them
works, of course. ;-)
hmyes, but it *should* be to use php://input and forget
about $HTTP_RAW_POST_DATA alltogether hopefully ...
--
Zitat von Hartmut Holzgraefe <[EMAIL PROTECTED]>:
> Jan Schneider wrote:
> > Do you mean, this is your plan or this already works?
>
> php://input already works with apache 1.x
>
> it should be SAPI independant, but for some strange
> reason it doesn't work for CGI right now, and i haven't
> tes
Jan Schneider wrote:
Do you mean, this is your plan or this already works?
php://input already works with apache 1.x
it should be SAPI independant, but for some strange
reason it doesn't work for CGI right now, and i haven't
tested any other SAPIs yet
but with the apache 1 module i already use
Tuesday, November 12, 2002, 12:02:52 PM, Hartmut Holzgraefe wrote:
> But in some cases it might be necessary to deal with 'raw' POST data.
> One of these cases is input that assigns multiple values to the same
> field name. PHP post data handlers will overwrite previous values for
> that field unle
Zitat von Hartmut Holzgraefe <[EMAIL PROTECTED]>:
> My approach was to provide a php://input stream instead of the
> $HTTP_RAW_POST_DATA
> variable and additional cleanup code that would swallow any unread
> content on
> request shutdown. php://input provides the same flexibility as
> $HTTP_RAW_PO
PHP parses POST data for known content types like application/x-www-form-urlencoded
and multipart/form-data and creates appropriate Variables containing form input on
the fly. It is even possible to register additional POST data handlers, e.g. the
fdf extension does this for application/vnd.fdf as
15 matches
Mail list logo
