TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
Weird hex numbers in the beginning and end of request response
  • rafirafi
    I'm baffled. What happens in more than one website (built with Kohana 3 latest official revision) is on some controllers, _only_ in production, the response to the browser comes back to the browser with a hex number at the very top, and "0" at the very end of the response. Something like this:


    204b
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"&gt;
    <html xmlns="http://www.w3.org/1999/xhtml&quot; xml:lang="en" lang="en">
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

    [...]

    </body>
    </html>
    0


    This happens on my server on webfaction, running PHP 5.2 and Apache. And on a different site, on a different server with PHP and Apache. It never happens when I work on the development platform, Windows 7 and Fedora 12. My best guess is that it has something to do with buffer memory, maybe it concerns php or apache, but I just can't figure out where is the problem.
  • shadowhandshadowhand

    Character 204b is a paragraph character. Your editor is probably adding some character that only appears on the Linux host.

  • rafirafi
    I went through all files, checked that there is no BOM in a hex editor, made sure all PHP files end with a comment and not ?>
    The hex I wrote was just an example, it changes when I modify the code. On one website where I had the problem, I mysteriously fixed it by breaking a long array in the middle like so:


    $pictures = array(
    array( ... ),
    array( ... ),
    [...]
    );
    $pictures += array(
    array( ... ),
    array( ... ),
    [...]
    );
  • bluehawkbluehawk

    Out of curiosity, what host are you on? I had this same problem on webfaction a while ago.

    There are a couple solutions, first, check what protocol your server is using, and which protocol header your app is sending. ( check $_SERVER['SERVER_PROTOCOL'] and then something like the firefox livehttpheaders addon) If the server and your app aren't on the same page then the "chunking" data (which is what you are seeing) gets sent wrong.

    A second fix is to send the Content-Length header, which is fairly simple. In your bootstrap do something like this:

     // psuedo code written off the top of my head, might be wrong
 $request->headers['Content-Length'] = strlen($request->response);
 echo $request->send_headers()->response();
  • rafirafi
    @bluehawk: Thanks for your answer. It is indeed something to do with data chunks. I saw this on my webfaction server a month ago, on a tiny website I quickly built, no database even, and for some reason I populated an array _within_ the view, don't ask me why I did it, it was probably late at night. The second time I saw it, was on the same site, I fixed it by updating Kohana core system to latest official revision. Again, I'm clueless.

    Last night we started seeing it in a much more critical place, a site that was requesting an XML from a controller on a different site. The XML came back with those hex numbers and thus simplexml wasn't able to parse it. It comes to be that simplexml_load_file is quite the same like file_get_contents which both suffer from a problem with large files. When we switched to cURL everything was working fine. Both sites are on a Rackspace cloud server.
  • bluehawkbluehawk

    I fixed it by updating Kohana core system to latest official revision. Again, I'm clueless.

    They fixed kohana to use SERVER_['SERVER_PROTOCOL'] by default, rather than having HTTP/1.1 hardcoded recently, i'm too lazy to find the specific ticket in redmine though :P

  • rafirafi
    Posted By: bluehawk

    I fixed it by updating Kohana core system to latest official revision. Again, I'm clueless.

    They fixed kohana to use SERVER_['SERVER_PROTOCOL'] by default, rather than having HTTP/1.1 hardcoded recently, i'm too lazy to find the specific ticket in redmine though :P



    YES!.. Now I remember vaguely a revision with the fix you mentioned. Well, I think this issue can be closed as solved. If I understand the flow of events:
    1) When the view had incorrect chunks of data transmitted through the request response, this issue was resolved in one of the latest core revisions.
    2) The issue with the simplexml_load_file was the large size of the response, which screwed up the data chunks. this was resolved by using cURL first to fetch the xml.
Add a Comment