Closed
Bug 384222
Opened 17 years ago
Closed 14 years ago
When web designer writes <title> with 7bit ascii only before <meta ... charset=us-ascii>, HTTP GET is issued again due to character set change
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: loren, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070612 Minefield/3.0a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070612 Minefield/3.0a6pre
When I click a link on my page, the new page loads twice. This can create an issue when using a link to processes something because it gets processed twice. I have temporarily fix the problem on part of the page by using a form with post data in which case the browser will not double load.
I demonstrated the issue to myself by using a counter to show the number of times the page was accessed by my php session id. If you need to see the counter (which I will be taking down shortly since this is a commercial site), email me and let me know.
Reproducible: Sometimes
Steps to Reproduce:
1. Click a link
2. If and when a white page shows up, the page has loaded twice. (This occurs fairly often on my sites, I haven't tried on others.)
Actual Results:
The page loads twice.
Expected Results:
The page loads once.
I have used the latest build with a clean profile and the default theme and FF 2.0.4 with my profile and a different theme and it occurs in both.
Comment 1•17 years ago
|
||
When Seamonkey 1.1.2(Win-XP SP2) with LiveHTTP Headers, slightly different result was obtained when I accessed http://klingmandesign.com/ (buy.php returned 404)
(Case-1) After cache clear
Two HTTP GET to http://klingmandesign.com/ was reported by LiveHTTPHheaders
when open the site from URL bar.
(tested with browser.cache.check_doc_frequency=1 only)
(Case-2) After access to the site sometimes
Two HTTP GET to http://klingmandesign.com/ was reported by LiveHTTPHheaders
only when Ctrl+Shift+R(Super Reload). Not occur when Ctrl+R(Normal Relaod).
(browser.cache.check_doc_frequency=1 and browser.cache.check_doc_frequency=3)
But I couldn't see this phenomenon when http://www.google.com.
Difference I can see in HTTP flow is following only.
A. Google returns "Cache-Control: private" and "Content-Length: 2756"
B. klingmandesign.com doesn't return above 2 headers.
Comment 2•17 years ago
|
||
To Loren Klingman:
Can you test next three cases by sending headers from PHP script?
1. Cache-Control:, No Content-Length:
2. No Cache-Control:, Content-Length:
3. Cache-Control:, Content-Length:
Comment 3•17 years ago
|
||
(Correction of difference)
A. Google returns "Cache-Control: private" and "Content-Length: 2756",
Content-Encoding: gzip. No Transfer-Encoding: chunked
B. klingmandesign.com doesn't return Cache-Control:, Content-Length,
and Content-Encoding:. Returns Transfer-Encoding: chunked
Loren Klingman, please ignore my Comment #2.
Affected by patch for Bug 330214?
Reporter | ||
Comment 4•17 years ago
|
||
I have fixed the link to buy.php.
Currently the script still runs the counter and I will leave it up as long as possible.
The counter shows just before Klingman Design-Buy Tickets.
It seems to be something of a content preload because it goes up 2 when you first view any link on the page (only buy.php views are tracked, not other pages), but does not go up 2 (only one) when pages are viewed a second time.
I will attempt to try some different headers and see if it fixes anything.
Comment 5•17 years ago
|
||
(In reply to comment #4)
> I have fixed the link to buy.php
Thanks, but no need to test with buy.php. buy.php is a victim of "two HTTP GET".
Problem of "two HTTP GET" is easily be re-created by main HTML of your site, and it's better for test because simple, and problem is easily be observed by LiveHTTPHeaders extension.
Reporter | ||
Comment 6•17 years ago
|
||
Another site on this server http://reflectionsig.com/home.php suffers no issues
and contains identical headers.
I thought it might have something to do with the domain so I visited my site
though another method http://reflectionsig.com/klingman/pricing.php and it
still does the double load.
I have now copied my main site to: http://alabasteryouth.com/test/ (different
server)
As far as I can tell (perhaps someone else can verify), this site does not have
the double GET issue.
http://reflectionsig.com/test/ is an exact replica of what was copied to the
other server but back on my main server and it has the problem.
IE 7 does not seem to suffer the issue on either site.
Therefore, is this an issue on my end, hosting, or FF? It seems odd to me that
my other sites on the same server suffer no issues while this site does.
Comment 7•17 years ago
|
||
(In addition to comment #3)
Another special one when http://klingmandesign.com/.
Expiration date of Epoc Time is set in cache.
(about:cache/Disk cache device, after Ctrl+Shift+R several times)
(Tested with Firefox trunk 2007/6/12 build)
Key: http://klingmandesign.com/space.gif
Data size: 85 bytes
Fetch count: 1
Last modified: 2007-06-13 11:53:34
Expires: 2007-06-24 09:33:33
Key: http://klingmandesign.com/
Data size: 4237 bytes
Fetch count: 1
Last modified: 2007-06-13 11:53:36
Expires: 1970-01-01 09:00:00
Key: http://klingmandesign.com/favicon.ico
Data size: 0 bytes
Fetch count: 13
Last modified: 2007-06-13 11:50:48
Expires: No expiration time
Comment 8•17 years ago
|
||
(In reply to comment #6)
> http://reflectionsig.com/home.php suffers no issues and contains identical headers.
> http://reflectionsig.com/klingman/pricing.php and it still does the double load.
I confirmed it, with Seamonkey 1.1.2. Same header, and Epoc Time in cache.
What is difference?
Reporter | ||
Comment 9•17 years ago
|
||
(In reply to comment #8)
>
> I confirmed it, with Seamonkey 1.1.2. Same header, and Epoc Time in cache.
> What is difference?
>
I have no idea.
Here are the page sources:
http://reflectionsig.com/test/index.txt (klingman design)
http://reflectionsig.com/test/home.txt (reflections ig)
Most of the includes are not php and so can be viewed already.
Here is one include for the home file:
http://reflectionsig.com/test/what.txt
Comment 10•17 years ago
|
||
Comment 11•17 years ago
|
||
Attached is log of next test. (Seamonkey trunk 2007/5/12 build is used)
1. Browse http://klingmandesign.com/ and shutdown. => Written in disk cache
2. Restart with NSPR log on(all:5)
2-1. Open the page from URL bar
2-2. Open new tab, about:config (To put separator of 2-1 and 2-3)
2-3. Ctrl+Shift+R at first tab => Double HTTP GET
Comment 12•17 years ago
|
||
(In reply to comment #9)
> http://reflectionsig.com/test/index.txt (klingman design)
> http://reflectionsig.com/test/home.txt (reflections ig)
Difference:
A. klingman design : PHP script in a HTML file
B. reflections ig : PHP script only, then puts all HTML lines from script
(Similar to echo '<tag>...' in PHP)
Depends on Apache+PHP behavior? Difference of SAPI PHP and CGI PHP?
Comment 13•17 years ago
|
||
NSPR log of next (Firefox trunk 2007/6/12 build is used)
1. Clear cache, and terminate Firefox
2. Restart Firefox with NSPR logging on. (Double HTTP GET at 2.2)
2-1. From URL bar, go to http://reflectionsig.com/home.php
2-2. From URL bar, go to thttp://reflectionsig.com/klingman/pricing.php
Comment 14•17 years ago
|
||
Possibly internal reload by character set change.
HTML of pricing.php(klingmandesign.com too) is as follows.
<head>
<title>Klingman Design - Pricing</title>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
When <title> is detected, iso-8859-1 is probably used because all character in <title> is 7bit ascii only. Then, when <meta ... charset=us-ascii> is detected, internal reload by character set change may occur. (This is current design, and different behavior from IE)
If above guess is correct, moving <title> after <meta ... charset> is a workaround. (This is recommended HTML coding style.)
Comment 15•17 years ago
|
||
This bug is one of "some cases" of Bug 288462 Comment #0, I think.
Reporter | ||
Comment 16•17 years ago
|
||
Moving the title does seem to rectify the program, but doesn't explain why http://alabasteryouth.com/test/ which has the title at the old spot has no issues.
The title was moved at http://reflectionsig.com/test/ because it will take me a while to fix it on the production site due to the way it is coded.
Comment 17•17 years ago
|
||
Changing summary for ease of search.
Summary: When loading pages they can load and then reload creating issues on some sites → When web designer writes <title> with 7bit ascii only before <meta ... charset=us-ascii>, HTTP GET is issued again due to character set change
Comment 18•17 years ago
|
||
(In reply to comment #16)
> Moving the title does seem to rectify the program, but doesn't explain why
> http://alabasteryouth.com/test/ which has the title at the old spot has no
> issues.
I don't know why, but at least following difference exists.
>http://reflectionsig.com/klingman/pricing.php
> Transfer-Encoding: chunked
>http://alabasteryouth.com/test/
> Content-Encoding: gzip
When nalabasteryouth.com, since gzip'ed, analysis of HTML have to be started after download of whole data and unzip of it. But analysis of HTML is possible while downloading when reflectionsig.com, because "chunked".
Updated•17 years ago
|
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 20•17 years ago
|
||
To Loren Klingman(bug opener):
Install LiveHTTPHeaders extension. You can see HTTP header log easily.
- http://livehttpheaders.mozdev.org/index.html
This extension doesn't seems to support Firefox trunk yet. If you use Firefox trunk mainly, unzip ZIP version of Seamonkey release build, and install LiveHTTPHeaders to Seamonkey. You can see HTTP headers while you use Firefox trunk.
Comment 21•15 years ago
|
||
This sounds like a testcase/dup of bug 17889 - Changing character set reloads the page from web.
Updated•14 years ago
|
Component: General → HTML: Parser
QA Contact: general → parser
Not gonna special-case ASCII-only before the meta. Too tricky for too little benefit. (And looking at the site, the problem doesn't seem to be applicable to the originally reported site with the HTML5 parser.)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•