Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
Strange characters in IE6/7 ...
… only on the computer of my client … !? See her screendump … at the top!
On my Mac via Parallels everything ok!
I did look with BBEdit if there where any hidden characters in the sourcecode … but none!
Are there some people who can check this with IE on a PC? And are there any ideas how come? The url > www.misterdutch.nl/werkwijze
Last edited by RedFox (2007-11-30 12:54:26)
Offline
Re: Strange characters in IE6/7 ...
oooh, chunked encoding.
This is probably something related to HTTP headers or proxies.
I don’t see this in my browser. Are you using a proxy server?
Offline
Re: Strange characters in IE6/7 ...
Hi Ruud! I know nothing about these kind of things. So here we go! I don’t use a proxy server or do you mean the ISP?
Last edited by RedFox (2007-11-30 16:56:45)
Offline
Re: Strange characters in IE6/7 ...
Have your client look at the following settings in Internet Explorer:
- tools (extra)
- internet options
- advanced (geavanceerd)
- there are a few HTTP1.1 options there, are both of these checked? If not, try checking them both and otherwise try unchecking the HTTP1.1 option that mentions the use of a proxy.
Also check:
- tools (extra)
- internet opties
- connections (verbindingen)
- LAN settings (LAN verbindingen) [assuming a cable/ADSL connection is used] -> if any of those options are checked there, try unchecking those and see if it makes a difference.
Now, the explanation of the problem:
That code 309b you see at the top of the HTML page is related to the way the webserver encodes the page it sends to the browser: chuncked encoding. When a webserver wants to sent content to a client, it wants to indicate how long it is (content-length in bytes). For dynamic pages this is more difficult, because quite often you only know how long the page will be when the PHP script is finished spitting out HTML code. Chunked encoding works by sending the data in chunks. Each chunk has a known length which is announced at the beginning of the chunk (309b for the first chunk, which is hexadecimal and this equals 12443 bytes). After sending the entire chunk, the webserver looks if there is more data to send. If so, it sends another chunk, again announcing its size at the beginning, and if not the next chunk is empty, hence the 0 at the end of the HTML code.
You can simulate what happens in a terminal session, by typing: telnet www.misterdutch.nl 80 and then pasting the following text (you only have a few seconds before it disconnects) and hit enter a few times:
GET /werkwijze HTTP/1.1
Host: www.misterdutch.nl
Connection: closeOf course, this only works if the browser knows it is receiving chunked encoded data. Normally, this is announced in the HTTP response headers. In that ‘telnet’ example, you can see this as well:
HTTP/1.1 200 OK
Date: Fri, 30 Nov 2007 21:00:25 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8If for some reason that Transfer-encoding header is removed, then the browser assumes that the data was not “chunked encoded” and the chunk lengths (309b and 0) remain visible in the HTML code that is used to render the page.
The question now is, how does that header get lost… or doesn’t it get lost at all and is it a browser problem. The cause could be a malfunctioning proxy, a damaged browser. Perhaps even a braindead virusscanner that intervenes in the HTTP communication and does some filtering where it shouldn’t.
Offline
Re: Strange characters in IE6/7 ...
Wow Ruud, that’s a large chunk of help … :) … thank you! Next week I have an appointment with my client. So this is to be continued … stay tuned!
Offline
Re: Strange characters in IE6/7 ...
There was a proxyserver … turned it off and voilà … no strange(!) characters anymore. Thanks Ruud!
Offline
Re: Strange characters in IE6/7 ...
ruud wrote:
Now, the explanation of the problem:
That code 309b you see at the top of the HTML page is related to the way the webserver encodes the page it sends to the browser: chuncked encoding. When a webserver wants to sent content to a client, it wants to indicate how long it is (content-length in bytes). For dynamic pages this is more difficult, because quite often you only know how long the page will be when the PHP script is finished spitting out HTML code. Chunked encoding works by sending the data in chunks. Each chunk has a known length which is announced at the beginning of the chunk (309b for the first chunk, which is hexadecimal and this equals 12443 bytes). After sending the entire chunk, the webserver looks if there is more data to send. If so, it sends another chunk, again announcing its size at the beginning, and if not the next chunk is empty, hence the 0 at the end of the HTML code.
If for some reason that Transfer-encoding header is removed, then the browser assumes that the data was not “chunked encoded” and the chunk lengths (309b and 0) remain visible in the HTML code that is used to render the page.
The question now is, how does that header get lost… or doesn’t it get lost at all and is it a browser problem. The cause could be a malfunctioning proxy, a damaged browser. Perhaps even a braindead virusscanner that intervenes in the HTTP communication and does some filtering where it shouldn’t.
——————————————
Hi ruud
This is a great explanation of the problem I am having with one of my websites.
Tricky problem!
I am running 20+ websites and only one is having the chunked encoding issue ??
There is a reverse proxy but they are all behind it so I don’t think that is the issue.
Also the chunking issue happens on different computers with different OS and browsers, so I doubt it is browser settings.
This issue only started when I migrated the sites to a new server with later kernel, mysql and php versions, etc
The problem site is running under Textpattern version: 4.0.3 (r1188)
All the other websites are running under Textpattern version: 4.0.5 (r2466)
My question is: Do you think if I upgrade the problem site to Textpattern version: 4.0.5 (r2466) that it will resolve the problem?
Everything seems to suggest that it will.
My main worry is that a Textpattern upgrade will break the site as I have done a few (undocumented and forgotten) mods to Textpattern itself.
If you don’t have any other suggestions that I can try first, then I will have to go down that road and fix the site afterwards.
Thanks
Cambo
Offline
Pages: 1