Mozilla browsers request a page twice

Discussion in 'HTML' started by Gary Hasler, Mar 11, 2008.

  1. Gary Hasler

    Gary Hasler Guest

    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
    ----------------------------------------------------------
    ....[IMAGES ETC FOLLOW....]
     
    Gary Hasler, Mar 11, 2008
    #1
    1. Advertising

  2. Gary Hasler

    Bergamot Guest

    Gary Hasler wrote:
    > 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/

    --
    Berg
     
    Bergamot, Mar 11, 2008
    #2
    1. Advertising

  3. Gary Hasler

    Ed Mullen Guest

    Bergamot wrote:
    > Gary Hasler wrote:
    >> 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/
    >


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

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

    --
    Ed Mullen
    http://edmullen.net
    Lead me not into temptation (I can find the way myself).
     
    Ed Mullen, Mar 12, 2008
    #3
  4. Gary Hasler

    Gary Hasler Guest

    Ed Mullen wrote:
    >
    > Bergamot wrote:
    > > Gary Hasler wrote:
    > >> 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/
    > >

    >
    > 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.
     
    Gary Hasler, Mar 12, 2008
    #4
  5. ..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
     
    Michael Fesser, Mar 12, 2008
    #5
  6. Gary Hasler

    Gary Hasler Guest

    Michael Fesser wrote:
    >
    > .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


    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?
     
    Gary Hasler, Mar 12, 2008
    #6
  7. Gary Hasler wrote:

    > 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/
     
    Toby A Inkster, Mar 14, 2008
    #7
  8. Gary Hasler

    AnrDaemon Guest

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

    > .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=...');


    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.


    --
    Sincerely Yours, AnrDaemon <>
     
    AnrDaemon, Mar 31, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jonel Rienton

    ASP.Net and Mozilla browsers

    Jonel Rienton, Nov 28, 2003, in forum: ASP .Net
    Replies:
    5
    Views:
    2,287
    stefano mostarda
    Nov 28, 2003
  2. Chad Lupkes
    Replies:
    3
    Views:
    595
    Chad Lupkes
    Aug 16, 2003
  3. Jerry

    hack for mozilla browsers?

    Jerry, Feb 14, 2004, in forum: HTML
    Replies:
    13
    Views:
    1,061
    Toby A Inkster
    Feb 16, 2004
  4. Aidan
    Replies:
    12
    Views:
    755
  5. El Kabong

    Browsers, browsers! Quo vadis?

    El Kabong, May 11, 2007, in forum: HTML
    Replies:
    23
    Views:
    951
    dorayme
    May 13, 2007
Loading...

Share This Page