Thread: [Php-java-bridge-users] php://input (php_stream_input_read) is broken, please don't use it

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Massimo,

You are right, when calling fopen("php://input", "r") PHP version 5 may
crash or hang. Please do not use it until this PHP5 bug is fixed.

I have looked at php 5.2.5. In php_fopen_wrapper.c line 81 it reads the
raw_post_data and then increments the SG(read_post_bytes) even though it
hasn't read anything. The result is that SG(read_post_bytes) is twice the
CONTENT_LENGTH size, causing all sorts of strage side effects later on.

In your particular case it calls SAPI.c sapi_read_post_data() which reads
the input up to CONTENT_LENGTH bytes. Then you call php_fopen_wrapper.c
php_stream_input_read() which reads nothing but increments
SG(read_post_bytes) again. And finally sapi_cgi_read_post() is called from
sapi_deactivate() to consume any remaining input. The remaining input is
calculated as (unsigned)(CONTENT_LENGTH-SG(read_post_bytes)) which is
4294967296-CONTENT_LENGTH due to an overflow.

If you post that much data, it will work, I guess... :)

Do you report this bug to the PHP maintainers?

Regards,
Jost Boekemeier

17. Aug 2009 4:44 nachm. schrieb am <
php...@li...>:

 Hi Jost,

thank you for the reply.

> Is it a standalone web- or desktop application?

It is a standalone desktop application, but several tasks will also
interface a remote Web server, if/when a network connection is
available.

> Why do you need jetty for a desktop application?

I found it helps a lot to give structure and order to the
application(s). It takes care of potential CLASSPATH issues, it's easy
to setup and start/stop, and has a small footprint. Last but not least,
it keeps a door open for more advanced functionality I may need in the
future - this is just the first of (hopefully) several applications.

> If you want to use PHP as a plugin only, use the JSR 223 API.

I am currently trying to connect the Swing application with Jetty-hosted
PHP scripts via JSON-RPC, since the (RAW POST based) protocol is quite
efficient and easy to implement, both in PHP and in Java.

Sadly though, while I can readily access the RAW POST data via
php://input and can also write the JSON string received from Java to a
file, I see the fastcgi is unable to output the response ... looks like
the communication channel is corrupted somehow as soon as I fopen it for
reading.

On the grounds that I may be violating the standard way of interacting
with a servlet, I've been struggling the past few days to solve the
problem by using java_context() methods and properties, but without
success so far ... I'd appreciate some advice.

Massimo

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
php-java-bridge-users mailing list
php...@li...
https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users