Frapi tries to parse request body as XML when it shouldn't

[denilsonsa]

In order to reproduce this bug, try sending this request:

POST /foobar HTTP/1.1
Host: foobar
content-type: application/x-www-form-urlencoded
content-length: 4

foo=

You can save it to a file and then run { cat foobar.txt ; sleep 10 ; } | telnet 127.0.0.1 80

The response is:

HTTP/1.1 200 OK
Date: Mon, 28 Apr 2014 19:48:54 GMT
Server: Apache/2.4.6 (Ubuntu)
X-Powered-By: PHP/5.5.3-1ubuntu2.3
Vary: Accept-Encoding
Content-Length: 467
Content-Type: text/html

<br />
<font size='1'><table class='xdebug-error xe-fatal-error' dir='ltr' border='1' cellspacing='0' cellpadding='1'>
<tr><th align='left' bgcolor='#f57900' colspan="5"><span style='background-color: #cc0000; color: #fce94f; font-size: x-large;'>( ! )</span> Fatal error: Uncaught String could not be parsed as XML
  thrown in /home/myself/frapi/src/frapi/library/Frapi/Input/RequestBodyParser.php on line <i>48</i></th></tr>
</table></font>

This response is wrong for many reasons:

• It shouldn't be HTTP 200 OK.
• It shouldn't return HTML error to the client.
• It shouldn't expose the path of the PHP file to the client.

This bug happens because of the following code from https://github.com/frapi/frapi/blob/master/src/frapi/library/Frapi/Controller/Main.php#L351 :

if (end($puts) == '' && !empty($inputFormat) || !empty($xmlJsonMatch)) {

Note that, if the request body is foo=bar instead of foo= (and, of course, the content-length header is updated to 7), then the bug will not happen, because end($puts) == '' will be false.