warmwinter / hessianphp

Automatically exported from code.google.com/p/hessianphp
MIT License
0 stars 0 forks source link

mbstring.func_overload compatibility #1

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
When mbstring.func_overload is enabled and the binary data contains what
looks like a unicode character, the call to strlen() in HessianStream.php
produces a length in characters rather than a length in bytes as intended.
This in turn triggers a "read past end of file" exception.

This problem can be eliminated by retrieving the length in bytes from the
HTTP stream or curl. I've attached a patch against svn trunk rev. 11.

Original issue reported on code.google.com by goo...@janderson.ca on 26 Mar 2010 at 10:57

Attachments:

GoogleCodeExporter commented 9 years ago
Thank you for the patch. I've been unable to reproduce the condition described 
but
there's a new unit test that includes some unicode characters and the master 
unit
test file is now UTF-8. Since the suggested changes seem logical and the unit 
tests
still pass, the patch has been applied to the main trunk, although more testing 
is
probably needed.

Original comment by vegeta...@gmail.com on 31 May 2010 at 6:52

GoogleCodeExporter commented 9 years ago
You can see the effect by setting mbstring.func_overload=2 and
mbstring.internal_encoding="UTF-8" in php.ini, then doing strlen("λ") -> gives 
1,
rather than it's binary length of 2.

func_overload can't be set at runtime which might make solid unit testing of the
problem difficult. 

Passing the lengths directly from the transport layer eliminates the problem 
anyway.
(I consider the issue closed... But I can't resolve it even though I created 
it.)

Original comment by goo...@janderson.ca on 31 May 2010 at 2:01

GoogleCodeExporter commented 9 years ago
It turns out, the patch breaks completely when interacting with Java Spring 
enabled
Hessian Services because, for some reason, the 'download_content_length' 
attribute in
CURL metadata returns -1. Tested in real case scenario. Temporarily reverting 
back to
original until a better solution is found, somewhere along the lines of 
automatic
mb_string recognition or enhanced parsing.

Original comment by vegeta...@gmail.com on 1 Jun 2010 at 3:45

GoogleCodeExporter commented 9 years ago
The issue has been apparently solved in the latest version (both in trunk and
downloads). The trick was in fact to detect PHP's internal encoding (mbstring) 
and
not to use strlen or substr for byte manipulation. Tested in PHP 5.2.9 (Apache) 
and
PHP 5.3 (IIS) with mbstring.func_overload=2 and 
mbstring.internal_encoding="UTF-8"
and both options disabled as well. Now, to be honest, those options look like 
nothing
but trouble hehe.

Original comment by vegeta...@gmail.com on 2 Jun 2010 at 9:04