Mozilla browsers request a page twice

[Gary Hasler]

I am having various problems with web pages on our site not displaying
the result of form submissions properly for users with Mozilla type
browsers (eg Firefox, Netscape). After investigation I have determined
it is because Mozilla often (but not always) repeats the request for a
web page. Therefore, when a page is showing the result of a form
posting or a redirect, the second request either has no results to show
or is repeating the submission! (although it seems to be happening with
all types of PHP pages, not just ones that result from POSTs).

I have fiddled with the HTTP response header the server is sending, and
searched my code for what could be causing this. I have also looked
through the Mozilla bug list but there is just so much gory detail of
charsets, encoding, caching, etc, that I don't have a clue if I'm
looking in the right direction. Has anyone seen this behaviour before
and can help me?

For instance the add-on "LiveHTTPHeaders" shows these headers, as the
result of a single click on a link to the page
http://www.thelogconnection.com/stockplan_A.php?plan=Monashee
(note in this case, a 'GET', the request and response are repeated
identically):
----------------------------------------------------------
http://www.thelogconnection.com/stockplan_A.php?plan=Monashee

GET /stockplan_A.php?plan=Monashee HTTP/1.1
Host: www.thelogconnection.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12)
Gecko/20080201 Firefox/2.0.0.12
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.thelogconnection.com/stock_plans3.html
Cookie: Pricequote_Form=
.....[SNIP COOKIE CONTENTS]...

HTTP/1.x 200 OK
Date: Tue, 11 Mar 2008 22:20:35 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
----------------------------------------------------------
http://www.thelogconnection.com/stockplan_A.php?plan=Monashee

GET /stockplan_A.php?plan=Monashee HTTP/1.1
Host: www.thelogconnection.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12)
Gecko/20080201 Firefox/2.0.0.12
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.thelogconnection.com/stock_plans3.html
Cookie: Pricequote_Form=
.....[SNIP COOKIE CONTENTS]...

HTTP/1.x 200 OK
Date: Tue, 11 Mar 2008 22:20:35 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

 

[Bergamot]

I am having various problems with web pages on our site not displaying
the result of form submissions properly for users with Mozilla type
browsers (eg Firefox, Netscape). After investigation I have determined
it is because Mozilla often (but not always) repeats the request for a
web page.

You might post something on the mozillazine forums:
http://mozillazine.org/

 

[Ed Mullen]

You might post something on the mozillazine forums:
http://mozillazine.org/

And these groups on news.mozilla.org may help:

mozilla.general
mozilla.support.seamonkey
mozilla.support.firefox

 

[Gary Hasler]

And these groups on news.mozilla.org may help:

mozilla.general
mozilla.support.seamonkey
mozilla.support.firefox

That seems to have done the trick. For those who are interested, it
looks like it was caused by having meta tag references to content-type
and "charset" in the document head. (Evidently Mozilla would start
loading the page, encounter the meta tag and decide it needed to reload
the whole page in a different mode.) I removed them all and that seems
to have worked. Good grief! And I still don't know why only pages with
..php extension were affected.

 

[Michael Fesser]

..oO(Gary Hasler)

That seems to have done the trick. For those who are interested, it
looks like it was caused by having meta tag references to content-type
and "charset" in the document head. (Evidently Mozilla would start
loading the page, encounter the meta tag and decide it needed to reload
the whole page in a different mode.) I removed them all and that seems
to have worked. Good grief! And I still don't know why only pages with
.php extension were affected.

Your server doesn't send any charset information. You should fix that.
Currently every browser has to guess and fall back to its own default,
which might cause a lot of new problems.

In PHP this can be accomplished with a header() call:

header('Content-Type: text/html; charset=...');

Additionally you should remove the line

<meta http-equiv="CONTENT-LANGUAGE" content="EN">

Such language information belongs to the 'html' element:

<html lang="en">

Micha

 

[Gary Hasler]

.oO(Gary Hasler)


Your server doesn't send any charset information. You should fix that.
Currently every browser has to guess and fall back to its own default,
which might cause a lot of new problems.

In PHP this can be accomplished with a header() call:

header('Content-Type: text/html; charset=...');

Additionally you should remove the line

<meta http-equiv="CONTENT-LANGUAGE" content="EN">

Such language information belongs to the 'html' element:

<html lang="en">

Micha

Thanks for the tips Micha(el). Charsets are a big mystery to me. All
our site is in plain English so should I specify ISO-8859-1 which I
understand is the default for HTTP1? And I can probably do it on our
(hosted) server using the .htaccess file rather than in every php and
html file?

 

[Toby A Inkster]

Thanks for the tips Micha(el). Charsets are a big mystery to me. All
our site is in plain English so should I specify ISO-8859-1 which I
understand is the default for HTTP1?

You should specify ISO-8859-1 is you're *using* ISO-8859-1. The URL you
posted earlier[1] seems to be using US-ASCII as its character set. As US-
ASCII is a subset of virtually every other character set in common usage,
you could set an HTTP header of virtually any character set you like,
including US-ASCII, ISO-8859-1 and UTF-8.

The fact that your site is in English is not particularly relevant. You
could create a web page in Japanese which could still be ISO-8859-1 or US-
ASCII. The character set is all to do with how particular characters are
represented. For example, if your document has a pound sign (£) in it, and
you save it as UTF-8, it will be represented by a two byte sequence:

0xC2 0xA3

But if you save it as ISO-8859-1, it will be stored as a single byte:

0xA3

(The fact that they both contain 0xA3 is not a coincidence. Unicode
intentionally re-uses the numbering of several legacy character sets.)

If you try to save it as US-ASCII, then you should be refused, because the
US-ASCII character set simply does not contain the pound sign. However,
it's still possible to represent a pound sign in US-ASCII web pages by
substituting an HTML entity instead:

&pound; OR £ OR £

Now if a web page contains the byte sequence "0xC2 0xA3" how does a web
browser know the proper way of displaying it? If UTF-8 is in use, it's
clearly a pound sign. But if ISO-8859-1 is in use, then the 0xA3 alone is
taken to be a pound sign, and the 0xC2 is another character altogether
(it's an accented A).

So you see now why it's important to know what character set you're using?
Without knowing the character set, you can't know what character a
particular byte (or sequence of bytes) is supposed to represent.

So anyway, assuming that the URL posted earlier is typical of your site,
you should be safe to mark your pages as ISO-8859-1.

For future projects though, I'd recommend picking a character set to use
from the outset (and there's very rarely a reason to pick anything other
than UTF-8 these days), and set all your tools (text editors, php.ini,
etc) to use that character set only.

____
1. http://www.thelogconnection.com/stockplan_A.php?plan=Monashee

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 44 days, 16:58.]
[Now Playing: Kenickie - People We Want]

The Semantic Web
http://tobyinkster.co.uk/blog/2008/03/09/sw/

 

[AnrDaemon]

Greetings, Michael Fesser.
In reply to Your message dated Wednesday, March 12, 2008, 20:45:26,

.oO(Gary Hasler)

Your server doesn't send any charset information. You should fix that.
Currently every browser has to guess and fall back to its own default,
which might cause a lot of new problems.

In PHP this can be accomplished with a header() call:

header('Content-Type: text/html; charset=...');

I'd recommend to set it in the php.ini
Directives

default_mimetype = "text/plain"
default_charset = "cp866"

I've used these for console development.
For the server environment it is

default_mimetype = "text/html"
default_charset = "Windows-1251"

for me.