Prologue:
---------
A few years ago, there was a discussion on how annoying the <BLINK> tag
is. Someone then described how he managed to overcome the blinking: He
opened Netscape Navigator 2.0 with a disk editor and replaced every
occurrence of "BLINK" with "BLONK". This did the trick -- no more
blinking text.

Smooth browsing with Netscape Navigator:
----------------------------------------
Now there is the annoying problem that Netscape Navigator loads and
renders some pages twice. Thanks to the pages: 

<http://www.euronet.nl/~tekelenb/WWW/netscapebug/>
<http://ppewww.ph.gla.ac.uk/~flavell/charset/ns-burp.html>

I learned that this is triggered by the occurrence of the line:

<META HTTP-EQUIV="Content-type" CONTENT="text/html;charset=something">

after the beginning of the page. If Netscape Navigator find a charset
definition, then it will send a second request to the http server to
confirm the correct charset. This may not sound very logical (since it
just got a charset declaration) but that's how I understood the problem.
Then Netscape Navigator will reload and render the page a second time.

Now I wondered whether the old trick might work here: obscuring the
keyword so that Netscape Navigator won't recognize it any more. So I
replaced one occurrence of "CHARSET" with "XHARSET" and it worked! No
more multiple reloads and redraws! It finally passed all three tests on
Sander Tekelenburg's test page.

Of course, the keyword "CHARSET" appears several times in the
application file. I found, for the 68K version of the stand-alone
browser Navigator 4.0.6, that the correct spot to be patched is at
offset $066D48 within the resource DATA ID=0. The attached screen shot
shows this location in ResEdit's generic Hex editor. (Note that this
resource is rather large -- you'll have to raise ResEdit's default
memory partition before opening the resource.)

I also found that this part of the resource looks like an index or a
dictionary. If you read on through the resource you can find the
following text:

   CHARSET= BOUNDARY= AUTOSCRO L@ A C EPT-RANGES: A L OW-RANGES: BYTES
   CONTENT-DISPOSITION: filename= CONTENT-TYPE: CONTENT-LENGTH:
   CONTENT-ENCODING: CONTENT-RANGE: bytes %lu-%lu/%lu@ CO N ECTION: , K
   E P-ALIVE DATE: EXPIRES: EXT-CACHE: name= instructions= LOCATION:
   LAST-MODIFIED: LINK: rel= pageServices PROXY-AUTHENTICATE: PROXY -CO
   N ECTION: PRAGMA: NO-CACHE RANGE: REFRESH: URL= SET-C O KIE: SERVER:
   NETSITE NETSCAPE !W -AUTHENTICATE: !W -PROTECTION-TEMPLATE:
   WINDOW-TARGET:

Note that I only replaced all control characters with spaces; otherwise
that's how the mentioned spot in the resource DATA ID=0 looks like. 

As already mentioned, this is for the 68k Version of the stand-alone
browser Navigator 4.0.6. But with these hints provided, you may find the
right spot to patch in other versions of Navigator/Communicator, too.
I'm not sure, however, how the 68k and PPC versions differ in this
aspect. In PPC applications, most of the code is in the data fork rather
than in the resource fork, so you may have to search there.

Problems and side effects:
--------------------------
I don't expect any major problems. Most web pages use the charset
ISO-8859-1 and that's what Netscape Navigator defaults to. Preliminary
checks with some German web pages showed that they are still displayed
correctly -- with German umlauts and the sz ligature correctly
translated to the Macintosh character set.

This patch shouldn't affect the normal operation of the browser.
Usually, web browsers will simply ignore everything they don't
understand. The META tags in the header section of a hypertext document
may contain many more information which is simply irrelevant to the
browser. Some information is rather meant for web crawlers, and some is
included for informational purpose only.

Hope it helps,

Hartmut