We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 22629
    • 194 Posts
    I’m currently developing my own C RSS feed poller, and I’ve noticed that in the HTTP response returned by MODx pages, there are a couple of spurious characters and I don’t know why they’re there. Take a look...

    # telnet vdev2-sanctree.networkmail.eu 80
    Trying 192.168.0.102...
    Connected to vdev2.networkmail.eu.
    Escape character is ’^]’.
    GET /index.php?id=310 HTTP/1.1
    Host: vdev2-sanctree.networkmail.eu

    HTTP/1.1 200 OK
    Date: Fri, 29 Aug 2008 15:46:10 GMT
    Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.8h DAV/2 PHP/5.2.6
    X-Powered-By: PHP/5.2.6
    P3P: CP="NOI NID ADMa OUR IND UNI COM NAV"
    Cache-Control: private, must-revalidate
    Set-Cookie: SN48a34638a7af9=qav3vldajmriha7ocg5d3gtd92; path=/
    Set-Cookie: SN48a34638a7af9=qav3vldajmriha7ocg5d3gtd92; path=/
    Transfer-Encoding: chunked
    Content-Type: application/rss+xml; charset=UTF-8

    226f
    <?xml version="1.0" standalone="yes"?>
    <rss version="2.0">

    ...

    </rss>
    0

    Connection closed by foreign host.

    What is the "226f" and "0" for? They’re certainly not in any of my templates or content. If I take the MODx site offline and request the page again, they’re not there, as below...

    # telnet vdev2-sanctree.networkmail.eu 80
    Trying 192.168.0.102...
    Connected to vdev2.networkmail.eu.
    Escape character is ’^]’.
    GET /index.php?id=310 HTTP/1.1
    Host: vdev2-sanctree.networkmail.eu

    HTTP/1.0 503 Service Unavailable
    Date: Fri, 29 Aug 2008 15:49:55 GMT
    Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.8h DAV/2 PHP/5.2.6
    X-Powered-By: PHP/5.2.6
    P3P: CP="NOI NID ADMa OUR IND UNI COM NAV"
    Cache-Control: private, must-revalidate
    Set-Cookie: SN48a34638a7af9=692uubpm88t9eda56kf359na53; path=/
    Set-Cookie: SN48a34638a7af9=692uubpm88t9eda56kf359na53; path=/
    Content-Length: 779
    Connection: close
    Content-Type: text/html; charset=UTF-8

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

    ...

    </html>Connection closed by foreign host.
      Andy Shellam | www.networkmail.eu | @Pandy06269 @NetworkMail

      modx Revolution 2.2.6
      Windows 2012 | IIS 8 | php 5.4.11 | MySQL 5.5.29

      Content-Managed Websites Built on MODX
      • 10449
      • 956 Posts
      The site you’re seeing when you decide it’s offline is not the same as the regular site, so that comparison doesn’t make sense.

      Post the original link to that page?
      Apparently, the first strange character is this:
      http://www.fileformat.info/info/unicode/char/226f/index.htm

      It’s gotta be coming from somewhere... a Ditto template, an accidentally pasted character/line from MS-Word or what have you...

      If you’re sure none of your pages/templates are to blame, analyse your main index.php file or the config-file. Maybe the first line got corrupted somehow...
        • 22629
        • 194 Posts
        Quote from: ganeshXL at Aug 29, 2008, 05:35 PM

        The site you’re seeing when you decide it’s offline is not the same as the regular site, so that comparison doesn’t make sense.

        I know this; I did the comparison to show that it’s not the HTTP server (i.e. Apache) generating these extra characters.

        Quote from: ganeshXL at Aug 29, 2008, 05:35 PM
        It’s gotta be coming from somewhere... a Ditto template, an accidentally pasted character/line from MS-Word or what have you...

        It’s on every page, the above output was on my test website but it’s also on my live site. The thing I don’t understand is, these extra characters don’t show up when you visit one of my web pages and view its source.

        You could ask where my issue is then if it’s not affecting the site. I’m asking because I couldn’t find any reference in the HTTP RFC that mentions extra characters in the body of the response, but it appears that both IE and Firefox know to filter them out. Therefore my C application needs to do the same thing.

        Quote from: ganeshXL at Aug 29, 2008, 05:35 PM
        If you’re sure none of your pages/templates are to blame, analyse your main index.php file or the config-file. Maybe the first line got corrupted somehow...

        The character is different on my test and live sites. On live it’s 322d, not 226f. The test site is a re-worked version of the live, with a clean install of MODx 0.9.6.2-rc2 on a different server with different operating systems, but the same PHP and Apache setup, and MySQL 5.1 on test (5.0 on live.)

        The MODx install on test was a clean install with a copy of the live database upgraded.
          Andy Shellam | www.networkmail.eu | @Pandy06269 @NetworkMail

          modx Revolution 2.2.6
          Windows 2012 | IIS 8 | php 5.4.11 | MySQL 5.5.29

          Content-Managed Websites Built on MODX
          • 28042 ☆ A M B ☆
          • 24,524 Posts
          It’s got to be something in your particular installation; maybe a plugin? That ending 0 looks very much like some kind of function return value.

          I’ve tested this on my pretty much vanilla installation, and there’s nothing like that.
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
            • 18086
            • 2 Posts
            I must say that i have a very similar problem with the strange characters. In most cases they are not a problem for the browsers although i have two responses regarding this issue: the website is displayed in MSIE 6 (some early version) with corrupted characters (rectangulars instead of polish national letters).
            MODx version 0.9.6.1p2
            Version codename rev 3281

            If i find some solution i will let know.

            ps.: i just checked ditto, maxigallery and wayfinder php files- no sign of ’154a’ string.
              • 22629
              • 194 Posts
              Please note the issue and solution has been identified thanks to another forum user who PM’d me.

              It’s a mechanism called "chunked transfer encoding" and the first number and closing "0" are markers for the data that appear to be used when there is no "content-length" header.

              The solution? Send a Content-Length header from modx, or change the polling application to identify these characters.

              http://en.wikipedia.org/wiki/Chunked_transfer_encoding
                Andy Shellam | www.networkmail.eu | @Pandy06269 @NetworkMail

                modx Revolution 2.2.6
                Windows 2012 | IIS 8 | php 5.4.11 | MySQL 5.5.29

                Content-Managed Websites Built on MODX