Re: [PHP] HTTP_RAW_POST_DATA
Michal Migurski wrote: Isn't this potentially a DoS attack vector anyway? I don't need a server to accept or read my obscenely long POST requests to clog the pipes with them. Would the proper way to handle this risk be to disallow POST at the webserver level, or does turning always_populate_raw_post_data off cause the connection to be automatically dropped after Connection: close? By default php streams the STDIN to a file so your just dealing with buffer sized ~2K-4K. enabling this option makes php put the contents into memory, thus leaving open the possiblity of someone using up all your memory and bringing the machine to a standstill till, then when swap space runs out.. watch out! :) This makes sense, thanks. Does not make sense to me. PHP must read the whole post stream to create $_POST and $HTTP_POST_VARS arrays, and to save file uploads into a temporary files. This happens before the script is executed. $HTTP_RAW_POST_DATA is just another variable occupying memory, and is not needed in 99.% of cases. It would make it more likely to hit php memory limit. Thus the option. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
--- Curt Zirzow [EMAIL PROTECTED] wrote: By default php streams the STDIN to a file so your just dealing with buffer sized ~2K-4K. enabling this option makes php put the contents into memory, thus leaving open the possiblity of someone using up all your memory and bringing the machine to a standstill till, then when swap space runs out.. watch out! :) Yeah, this is what my migs and megs of memories comment was meant to convey, although Curt's description is more detailed and eloquent. :-) Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
--- Marek Kilimajer [EMAIL PROTECTED] wrote: PHP must read the whole post stream to create $_POST and $HTTP_POST_VARS arrays, and to save file uploads into a temporary files. This happens before the script is executed. Well, there are other scenarios: POST /path/to/script.php HTTP/1.1 Host: example.org Content-Type: shiflett Content-Length: 384975438975438753495734957 dshgjkdfhgkldfjhgklsfjdhgkdfjhgksjdfhgjdfkghsdfjkg... :-) Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
Chris Shiflett wrote: --- Marek Kilimajer [EMAIL PROTECTED] wrote: PHP must read the whole post stream to create $_POST and $HTTP_POST_VARS arrays, and to save file uploads into a temporary files. This happens before the script is executed. Well, there are other scenarios: POST /path/to/script.php HTTP/1.1 Host: example.org Content-Type: shiflett Content-Length: 384975438975438753495734957 will be caught by the LimitRequestBody. That can only have a maximum of 2GB. You have demonstrated how easy it's to carry out a DOS with POST. -- Raditha Dissanayake. - http://raditha/megaupload/upload.php Sneak past the PHP file upload limits. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
* Thus wrote Chris Shiflett ([EMAIL PROTECTED]): --- Curt Zirzow [EMAIL PROTECTED] wrote: By default php streams the STDIN to a file so your just dealing with buffer sized ~2K-4K. enabling this option makes php put the contents into memory, thus leaving open the possiblity of someone using up all your memory and bringing the machine to a standstill till, then when swap space runs out.. watch out! :) Yeah, this is what my migs and megs of memories comment was meant to I suppose we'll be feeing rhino's and running from snakes rather shortly :) Curt -- I used to think I was indecisive, but now I'm not so sure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
Check the value of always_populate_raw_post_data in php.ini on both servers. Thats such a funny name. Not to mention misleading, since it doesn't always populate $HTTP_RAW_POST_DATA when enabled. Always should mean always. Anyone have any clue why this is the case? Is there a performance reason that raw post data must be explicitly enabled, or is it more of a protective measure for overly permissive beginner scripts? Inquiring minds demand answers! - michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
Chris Boget wrote: same configuration. Where would I look to discover why one server would have data held in $HTTP_RAW_POST_DATA whereas the other server would not? Check the value of always_populate_raw_post_data in php.ini on both servers. That was it. Thank you so very much!! Chris NOw I am very curious, the raw_post_data doesn't always get populated even with that setting. If i have not been barking up the wrong tree all these years that variable only gets populated if the content type is not url-encoded or multipart/form-data. If you are indeed using one of these types please be so kind as to share more info about your set up, this is something i would like to reproduce. best regards raditha -- Raditha Dissanayake. - http://www.radinks.com/print/upload.php SFTP, FTP and HTTP File Upload solutions -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
--- Michal Migurski [EMAIL PROTECTED] wrote: Anyone have any clue why this is the case? Is there a performance reason that raw post data must be explicitly enabled, or is it more of a protective measure for overly permissive beginner scripts? If it was always enabled, it sure would make a DoS attack easy. I'd just send lots of huge POST requests to any PHP script on your server. Hope you have migs and megs of memories, as Strong Bad would say. :-) Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
Anyone have any clue why this is the case? Is there a performance reason that raw post data must be explicitly enabled, or is it more of a protective measure for overly permissive beginner scripts? If it was always enabled, it sure would make a DoS attack easy. I'd just send lots of huge POST requests to any PHP script on your server. Hope you have migs and megs of memories, as Strong Bad would say. :-) Isn't this potentially a DoS attack vector anyway? I don't need a server to accept or read my obscenely long POST requests to clog the pipes with them. Would the proper way to handle this risk be to disallow POST at the webserver level, or does turning always_populate_raw_post_data off cause the connection to be automatically dropped after Connection: close? -mike. - michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
--- raditha dissanayake [EMAIL PROTECTED] wrote: NOw I am very curious, the raw_post_data doesn't always get populated even with that setting. If i have not been barking up the wrong tree all these years that variable only gets populated if the content type is not url-encoded or multipart/form-data. If you are indeed using one of these types please be so kind as to share more info about your set up, this is something i would like to reproduce. This is what our tangential conversation touched on. Curt mentioned that always_populate_raw_post_data is a funny name, and I mentioned how it was also misleading (always should mean always). I assume the original poster is using neither of the content types you mention, since this was already working for him in one environment. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
Chris Shiflett wrote: --- raditha dissanayake [EMAIL PROTECTED] wrote: NOw I am very curious, the raw_post_data doesn't always get populated even with that setting. If i have not been barking up the wrong tree all these years that variable only gets populated if the content type is not url-encoded or multipart/form-data. If you are indeed using one of these types please be so kind as to share more info about your set up, this is something i would like to reproduce. This is what our tangential conversation touched on. Curt mentioned that always_populate_raw_post_data is a funny name, and I mentioned how it was also misleading (always should mean always). I assume the original poster is using neither of the content types you mention, since this was already working for him in one environment. Hi, Thants what I am also thinking, i was quite taken aback to read the original post. shocked in fact. Raditha Dissanayake. - http://www.radinks.com/print/upload.php SFTP, FTP and HTTP File Upload solutions -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
Michal Migurski wrote: Anyone have any clue why this is the case? Is there a performance reason that raw post data must be explicitly enabled, or is it more of a protective measure for overly permissive beginner scripts? If it was always enabled, it sure would make a DoS attack easy. I'd just send lots of huge POST requests to any PHP script on your server. Hope you have migs and megs of memories, as Strong Bad would say. :-) Isn't this potentially a DoS attack vector anyway? I don't need a server to accept or read my obscenely long POST requests to clog the pipes with them. Would the proper way to handle this risk be to disallow POST at the webserver level, or does turning always_populate_raw_post_data off cause the connection to be automatically dropped after Connection: close? Well if you disallow post, you will have to use get for things like login in - insecure. And you will be limited to about 1024 bytes of data on most systems and you can't use file uploads. I guess you would know how to how to create malformed packets. Doing a dos attack on a PHP script that accepts POST you only need about 10 lines of code, don't need to know how to create malformed packets, and you don't waste your own bandwidth. -- Raditha Dissanayake. - http://www.radinks.com/print/upload.php SFTP, FTP and HTTP File Upload solutions -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
* Thus wrote Michal Migurski ([EMAIL PROTECTED]): Anyone have any clue why this is the case? Is there a performance reason that raw post data must be explicitly enabled, or is it more of a protective measure for overly permissive beginner scripts? If it was always enabled, it sure would make a DoS attack easy. I'd just send lots of huge POST requests to any PHP script on your server. Hope you have migs and megs of memories, as Strong Bad would say. :-) Isn't this potentially a DoS attack vector anyway? I don't need a server to accept or read my obscenely long POST requests to clog the pipes with them. Would the proper way to handle this risk be to disallow POST at the webserver level, or does turning always_populate_raw_post_data off cause the connection to be automatically dropped after Connection: close? The POST data basically sits in STDIN for the webserver, it will just sit there unless somebody like php reads that data and does something with it. By default php streams the STDIN to a file so your just dealing with buffer sized ~2K-4K. enabling this option makes php put the contents into memory, thus leaving open the possiblity of someone using up all your memory and bringing the machine to a standstill till, then when swap space runs out.. watch out! :) Curt -- I used to think I was indecisive, but now I'm not so sure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
Isn't this potentially a DoS attack vector anyway? I don't need a server to accept or read my obscenely long POST requests to clog the pipes with them. Would the proper way to handle this risk be to disallow POST at the webserver level, or does turning always_populate_raw_post_data off cause the connection to be automatically dropped after Connection: close? By default php streams the STDIN to a file so your just dealing with buffer sized ~2K-4K. enabling this option makes php put the contents into memory, thus leaving open the possiblity of someone using up all your memory and bringing the machine to a standstill till, then when swap space runs out.. watch out! :) This makes sense, thanks. - michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
From: Curt Zirzow [EMAIL PROTECTED] * Thus wrote John W. Holmes ([EMAIL PROTECTED]): Check the value of always_populate_raw_post_data in php.ini on both servers. Thats such a funny name. So is Zirzow ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
--- Curt Zirzow [EMAIL PROTECTED] wrote: Check the value of always_populate_raw_post_data in php.ini on both servers. Thats such a funny name. Not to mention misleading, since it doesn't always populate $HTTP_RAW_POST_DATA when enabled. Always should mean always. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
Chris Shiflett wrote: --- Curt Zirzow [EMAIL PROTECTED] wrote: Check the value of always_populate_raw_post_data in php.ini on both servers. Thats such a funny name. Not to mention misleading, since it doesn't always populate $HTTP_RAW_POST_DATA when enabled. Always should mean always. No, no, that's crazy talk. :-) cheers, Travis -- Travis Low mailto:[EMAIL PROTECTED] http://www.dawnstar.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] HTTP_RAW_POST_DATA
I was looking through the documentation and I could not figure out why the following is occuring: On our development server, I have a script that accesses the value of $HTTP_RAW_POST_DATA (upon form submission) and there is data there. However, on our production server, the same code shows no value held in $HTTP_RAW_POST_DATA. Both servers are running v4.3.2 and as far as I can tell, have the same configuration. Where would I look to discover why one server would have data held in $HTTP_RAW_POST_DATA whereas the other server would not? Anyone have suggestions for where I should be looking? thnx, Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
From: Chris Boget [EMAIL PROTECTED] On our development server, I have a script that accesses the value of $HTTP_RAW_POST_DATA (upon form submission) and there is data there. However, on our production server, the same code shows no value held in $HTTP_RAW_POST_DATA. Both servers are running v4.3.2 and as far as I can tell, have the same configuration. Where would I look to discover why one server would have data held in $HTTP_RAW_POST_DATA whereas the other server would not? Check the value of always_populate_raw_post_data in php.ini on both servers. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
* Thus wrote John W. Holmes ([EMAIL PROTECTED]): Check the value of always_populate_raw_post_data in php.ini on both servers. Thats such a funny name. Curt -- I used to think I was indecisive, but now I'm not so sure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
same configuration. Where would I look to discover why one server would have data held in $HTTP_RAW_POST_DATA whereas the other server would not? Check the value of always_populate_raw_post_data in php.ini on both servers. That was it. Thank you so very much!! Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] HTTP_RAW_POST_DATA
--- Sam Minnee [EMAIL PROTECTED] wrote: I'm having a couple of problems getting PHP to accept my post data. Specifically, the data I am sending is not with POST, put with PUT and PROPFIND. I'm implementing WebDAV within PHP. How to I get PHP to set $HTTP_RAW_POST_DATA for all methods where content is sent, not just post? Sam, You might want to look into the apache_hooks SAPI. It is experimental, but it will give you more flexibility in terms of working with Apache (and interacting with different phases). Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] HTTP_RAW_POST_DATA
Hi, I'm having a couple of problems getting PHP to accept my post data. Specifically, the data I am sending is not with POST, put with PUT and PROPFIND. I'm implementing WebDAV within PHP. How to I get PHP to set $HTTP_RAW_POST_DATA for all methods where content is sent, not just post? Thanks, Sam -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] HTTP_RAW_POST_DATA / Content-type
Hello, I'm running into a problem accessing $HTTP_RAW_POST_DATA in my scripts. I am interfacing with an external system that is doing a HTTP POST to my php script (I'm running 4.0.6). The variable $HTTP_RAW_POST_DATA is always blank even though the external system is sending me data. The problem is that the external system is not passing me a Content-type; they are including Content-length and the various other headers, but not Content-type. There is a known bug for this (http://bugs.php.net/bug.php?id=12208), and it seems that it is resolved in 4.0.7. Does anyone know of a patch for 4.0.6 that would resolve this bug? I wouldn't mind re-compiling 4.0.6 after patching the code, but I would rather not install 4.0.7 since it is still in the release candidate stage and the server in question is a production server. Thanks, Ryan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] HTTP_RAW_POST_DATA
Hi, Could anyone help me with altering PHP sources? Or tell me please where may I ask this question? The problem is when PHP handles a POST request of a known Content-type (e.g. x-www-form-urlencoded), it leaves $HTTP_RAW_POST_DATA blank. I need to alter the sources so that PHP would always put the request data into this variable. This would allow me to handle malformed POST requests. For example, if a client sends a request of Content-type x-www-form-urlencoded and the data is NOT really urlencoded, such request seems to get lost. I can't find the data neither in $HTTP_RAW_POST_DATA, nor in $HTTP_POST_VARS. I figured it would be great if PHP could always set $HTTP_RAW_POST_DATA independently of the Content-type. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] HTTP_RAW_POST_DATA
Dmitri Zasypkin wrote:
Hi,
Could anyone help me with altering PHP sources? Or tell me please where
may I ask this question?
The problem is when PHP handles a POST request of a known Content-type
(e.g. x-www-form-urlencoded), it leaves $HTTP_RAW_POST_DATA blank. I
need to alter the sources so that PHP would always put the request data
into this variable.
This would allow me to handle malformed POST requests. For example, if a
client sends a request of Content-type x-www-form-urlencoded and the
data is NOT really urlencoded, such request seems to get lost. I can't
find the data neither in $HTTP_RAW_POST_DATA, nor in $HTTP_POST_VARS. I
figured it would be great if PHP could always set $HTTP_RAW_POST_DATA
independently of the Content-type.
**WILD GUESS ALERT**
If you modify lines 140-150 of php4/main/SAPI.c from:
--
if (zend_hash_find(known_post_content_types, content_type,
content_type_length+1, (void **) post_entry)==SUCCESS) {
SG(request_info).post_entry = post_entry;
post_reader_func = post_entry-post_reader;
} else {
if (!sapi_module.default_post_reader) {
sapi_module.sapi_error(E_WARNING, Unsupported content type:
'%s', content_type);
return;
}
SG(request_info).post_entry = NULL;
post_reader_func = sapi_module.default_post_reader;
}
--
to:
--
SG(request_info).post_entry = NULL;
post_reader_func = sapi_module.default_post_reader;
--
you *may* get the behavior that you are looking for.
--zak
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] HTTP_RAW_POST_DATA
Zak,
Thank you for the answer. Are you sure $HTTP_POST_VARS will be still set after
that modification in case of a valid x-www-form-urlencoded POST request? I'm
afraid they won't.. Such side effect is very undesirable for me.
Anyway thanks.
Zak Greant wrote:
Dmitri Zasypkin wrote:
Hi,
Could anyone help me with altering PHP sources? Or tell me please where
may I ask this question?
The problem is when PHP handles a POST request of a known Content-type
(e.g. x-www-form-urlencoded), it leaves $HTTP_RAW_POST_DATA blank. I
need to alter the sources so that PHP would always put the request data
into this variable.
This would allow me to handle malformed POST requests. For example, if a
client sends a request of Content-type x-www-form-urlencoded and the
data is NOT really urlencoded, such request seems to get lost. I can't
find the data neither in $HTTP_RAW_POST_DATA, nor in $HTTP_POST_VARS. I
figured it would be great if PHP could always set $HTTP_RAW_POST_DATA
independently of the Content-type.
**WILD GUESS ALERT**
If you modify lines 140-150 of php4/main/SAPI.c from:
--
if (zend_hash_find(known_post_content_types, content_type,
content_type_length+1, (void **) post_entry)==SUCCESS) {
SG(request_info).post_entry = post_entry;
post_reader_func = post_entry-post_reader;
} else {
if (!sapi_module.default_post_reader) {
sapi_module.sapi_error(E_WARNING, Unsupported content type:
'%s', content_type);
return;
}
SG(request_info).post_entry = NULL;
post_reader_func = sapi_module.default_post_reader;
}
--
to:
--
SG(request_info).post_entry = NULL;
post_reader_func = sapi_module.default_post_reader;
--
you *may* get the behavior that you are looking for.
--zak
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] HTTP_RAW_POST_DATA
Actually, I am afraid that they won't.
To achieve this, break the if/else block up so that both code blocks are
called.
--zak
- Original Message -
From: Dmitri Zasypkin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 07, 2001 7:15 AM
Subject: Re: [PHP] HTTP_RAW_POST_DATA
Zak,
Thank you for the answer. Are you sure $HTTP_POST_VARS will be still set
after
that modification in case of a valid x-www-form-urlencoded POST request?
I'm
afraid they won't.. Such side effect is very undesirable for me.
Anyway thanks.
Zak Greant wrote:
Dmitri Zasypkin wrote:
Hi,
Could anyone help me with altering PHP sources? Or tell me please
where
may I ask this question?
The problem is when PHP handles a POST request of a known Content-type
(e.g. x-www-form-urlencoded), it leaves $HTTP_RAW_POST_DATA blank. I
need to alter the sources so that PHP would always put the request
data
into this variable.
This would allow me to handle malformed POST requests. For example, if
a
client sends a request of Content-type x-www-form-urlencoded and the
data is NOT really urlencoded, such request seems to get lost. I
can't
find the data neither in $HTTP_RAW_POST_DATA, nor in $HTTP_POST_VARS.
I
figured it would be great if PHP could always set $HTTP_RAW_POST_DATA
independently of the Content-type.
**WILD GUESS ALERT**
If you modify lines 140-150 of php4/main/SAPI.c from:
--
if (zend_hash_find(known_post_content_types, content_type,
content_type_length+1, (void **) post_entry)==SUCCESS) {
SG(request_info).post_entry = post_entry;
post_reader_func = post_entry-post_reader;
} else {
if (!sapi_module.default_post_reader) {
sapi_module.sapi_error(E_WARNING, Unsupported content type:
'%s', content_type);
return;
}
SG(request_info).post_entry = NULL;
post_reader_func = sapi_module.default_post_reader;
}
--
to:
--
SG(request_info).post_entry = NULL;
post_reader_func = sapi_module.default_post_reader;
--
you *may* get the behavior that you are looking for.
--zak
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
