Freepages-Help-L Archives
Archiver > Freepages-Help > 2002-12 > 1040834634
From: Elsi <>
Subject: Re: [FreeHelp] Re: Freepages Frames/Banner display
Date: Wed, 25 Dec 2002 10:43:58 -0600
References: <200212251300.gBPD0cmN017752@lists2.rootsweb.com>
In-Reply-To: <20021225153707.34974.qmail@web20910.mail.yahoo.com>
At 07:37 AM 12/25/2002 -0800, S. Hunter wrote:
>There is really a very simple way of accomplishing this. Simply
>save your files with the extention of .txt instead of .html. Be
>sure to change the corresponding file names in your frame loader
>file to filename.txt instead of filename.html. The freepages
>banner will only be displayed in the files with the HTML file
>extention, so just choose which frame file you want the banner
>in and name it as filename.html, while naming all your other
>frame files filename.txt. This will not affect anything about
>how your file displays except the freepages banner [as far a I
>can tell with my short experiment}.
>I have used this display 'trick' before with SSI files, to keep
>the server from servering up multiple banners on my pages and
>thought it would probably work with frames banners also. I put
>up a test file here
>http://freepages.genealogy.rootsweb.com/~powell/frames/frtest.html
>if you want to take a look. It worked for me...
Here's a classic example of generalizing from a single browser's behavior.
When a .txt file is served by most web servers (and certainly by the
RootsWeb server) it contains an HTTP header declaring the file content to
be plain text:
Content-type: text/plain
Netscape Navigator (all versions) honors the Content-type header and
displays all of your HTML tags there in the bottom frame. Internet
Explorer instead looks at the data and thinks "heck, there are some tags in
here, let me interpret them instead of displaying them". (This behavior in
Microsoft products is one of the reasons why we have to stick those periods
in HTML fragments we post to this list -- some people's mail readers
execute/interpret the tags instead of displaying them.)
Note that the IE behavior is contrary to the HTTP standard as defined in
RFC 2616 (ftp://ftp.isi.edu/in-notes/rfc2616.txt) section 7.2.1:
"Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If and only
if the media type is not given by a Content-Type field, the recipient MAY
attempt to guess the media type via inspection of its content and/or the
name extension(s) of the URI used to identify the resource. If the media
type remains unknown, the recipient SHOULD treat it as type
"application/octet-stream"."
The same text appears in the HTTP 1.0 specification in RFC 1945
(http://www.w3.org/Protocols/rfc1945/rfc1945) section 7.2.1.
Note the "if and only if" clause here. The browser is free to interpret
the contents of the HTTP message *if and ONLY if* the server doesn't
include one. IE ignores the Content-type header when it sees HTML in the
body of the message.
Regards,
Elsi
This thread: