Strange behavior with Service Side Include

**Lars Eighner** · Jul 31 '08, 10:35 PM

Re: Strange behavior with Service Side Include

In our last episode,
<f3886e1a-8130-4411-a4aa-b8ca90fe6ca6@w3 9g2000prb.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

I went to the Symark site, and poking around a little, I did not find this
exact footer. Nonetheless, let us reason together. It cannot possibly be
that you use SSI, because SSI is seamless to the browser. It must be that
the SSI text is not *exactly* like the previous script generated text.

You can copy and paste the SSI text into a test document to prove that
SSI is not at fault (which is theoretically impossible anyway, but some
people still need proof that water is wet). So then you have to compare the
served SSI document (i.e. view source) with the script generated source
until you discover what is different.

In particular, some versions of IE are known to not handle some whitespace
(especially newlines) between tags properly. You must make the SSI agree
*exactly* with the script generated text --- including spaces and newlines,
even where they shouldn't count --- to expect consistent results in IE.
A quick examination reveals that the SSI text is not exactly the same
as the script text in reguard to spaces and newlines.

--
Lars Eighner <http://larseighner.com/usenet@larseigh ner.com
War on Terrorism: Bad News from the Sanity Front
"There's one thing ... that I do like about Rumsfeld, he's just a little bit
crazy, OK"? --Thomas Friedman, _The New York Times_

**silverbob** · Jul 31 '08, 10:45 PM

Re: Strange behavior with Service Side Include

On Jul 31, 3:30 pm, Lars Eighner <use...@larseig hner.comwrote:

In our last episode,
<f3886e1a-8130-4411-a4aa-b8ca90fe6...@w3 9g2000prb.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:
>

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

>
I went to the Symark site, and poking around a little, I did not find this
exact footer. Nonetheless, let us reason together. It cannot possibly be
that you use SSI, because SSI is seamless to the browser. It must be that
the SSI text is not *exactly* like the previous script generated text.
>
You can copy and paste the SSI text into a test document to prove that
SSI is not at fault (which is theoretically impossible anyway, but some
people still need proof that water is wet). So then you have to compare the
served SSI document (i.e. view source) with the script generated source
until you discover what is different.
>
In particular, some versions of IE are known to not handle some whitespace
(especially newlines) between tags properly. You must make the SSI agree
*exactly* with the script generated text --- including spaces and newlines,
even where they shouldn't count --- to expect consistent results in IE.
A quick examination reveals that the SSI text is not exactly the same
as the script text in reguard to spaces and newlines.
>
--
Lars Eighner <http://larseighner.com/use...@larseigh ner.com
War on Terrorism: Bad News from the Sanity Front
"There's one thing ... that I do like about Rumsfeld, he's just a little bit
crazy, OK"? --Thomas Friedman, _The New York Times_

I just reformatted the HTML so that it is exactly like the javascript
text file (minus the "document.write "). It made no difference as I
would expect because HTML does not care how its formatted.

Then, I replaced the SSI call with the exact code being used in the
SSI file, and the footers display differently. Take a look:
http://www.symark.com/test6.html (This is the SSI version)
http://www.symark.com/test7.html (This is the same SSI HTML but
embedded in the page)

Remember. This is in IE.

BTW, when I view the page source, I see a little dot or something
preceding the SSI inserted code. Is this typical?

Regards, Bob

**silverbob** · Jul 31 '08, 11:05 PM

Re: Strange behavior with Service Side Include

On Jul 31, 3:30 pm, Lars Eighner <use...@larseig hner.comwrote:

In our last episode,
<f3886e1a-8130-4411-a4aa-b8ca90fe6...@w3 9g2000prb.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:
>

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

>
I went to the Symark site, and poking around a little, I did not find this
exact footer. Nonetheless, let us reason together. It cannot possibly be
that you use SSI, because SSI is seamless to the browser. It must be that
the SSI text is not *exactly* like the previous script generated text.
>
You can copy and paste the SSI text into a test document to prove that
SSI is not at fault (which is theoretically impossible anyway, but some
people still need proof that water is wet). So then you have to compare the
served SSI document (i.e. view source) with the script generated source
until you discover what is different.
>
In particular, some versions of IE are known to not handle some whitespace
(especially newlines) between tags properly. You must make the SSI agree
*exactly* with the script generated text --- including spaces and newlines,
even where they shouldn't count --- to expect consistent results in IE.
A quick examination reveals that the SSI text is not exactly the same
as the script text in reguard to spaces and newlines.
>
--
Lars Eighner <http://larseighner.com/use...@larseigh ner.com
War on Terrorism: Bad News from the Sanity Front
"There's one thing ... that I do like about Rumsfeld, he's just a little bit
crazy, OK"? --Thomas Friedman, _The New York Times_

This little dot I spoke of seems to be the source of my problem. You
can see it when you do a view source from IE, but it doesn't appear in
the source from Firefox.

- Bob

**Lars Eighner** · Aug 1 '08, 12:05 AM

Re: Strange behavior with Service Side Include

In our last episode,
<03fc3a18-cdb8-44a0-92d9-978d816e2339@a2 1g2000prf.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

On Jul 31, 3:30 pm, Lars Eighner <use...@larseig hner.comwrote:

>In our last episode,
><f3886e1a-8130-4411-a4aa-b8ca90fe6...@w3 9g2000prb.googl egroups.com>, the
>lovely and talented silverbob broadcast on
>comp.infosyste ms.www.authoring.html:
>>

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

>>
>I went to the Symark site, and poking around a little, I did not find this
>exact footer. Nonetheless, let us reason together. It cannot possibly be
>that you use SSI, because SSI is seamless to the browser. It must be that
>the SSI text is not *exactly* like the previous script generated text.
>>
>You can copy and paste the SSI text into a test document to prove that
>SSI is not at fault (which is theoretically impossible anyway, but some
>people still need proof that water is wet). So then you have to compare the
>served SSI document (i.e. view source) with the script generated source
>until you discover what is different.
>>
>In particular, some versions of IE are known to not handle some whitespace
>(especially newlines) between tags properly. You must make the SSI agree
>*exactly* with the script generated text --- including spaces and newlines,
>even where they shouldn't count --- to expect consistent results in IE.
>A quick examination reveals that the SSI text is not exactly the same
>as the script text in reguard to spaces and newlines.
>>
>--
>Lars Eighner <http://larseighner.com/use...@larseigh ner.com
> War on Terrorism: Bad News from the Sanity Front
>"There's one thing ... that I do like about Rumsfeld, he's just a little bit
> crazy, OK"? --Thomas Friedman, _The New York Times_

I just reformatted the HTML so that it is exactly like the javascript
text file (minus the "document.write "). It made no difference as I
would expect because HTML does not care how its formatted.

Then, I replaced the SSI call with the exact code being used in the
SSI file, and the footers display differently. Take a look:
http://www.symark.com/test6.html (This is the SSI version)
http://www.symark.com/test7.html (This is the same SSI HTML but
embedded in the page)

Remember. This is in IE.

BTW, when I view the page source, I see a little dot or something
preceding the SSI inserted code. Is this typical?

No. SSI is seamless to client. However there are/is some nonsense
characters after an few more tabs (than in test7). However the same
characters appear in several other places, so I assume it is some utf-8
dingbat, intentional or otherwise. Anyway, this appears to be the only
utf-8 that is in the document. Is it being served as utf-8? (and you do
know that meta http-equiv is useless, don't you? -- well, not entirely
useless, but has no effect whatever on how the document is served.)
Is the text for the SSI being saved as utf-8?

--
Lars Eighner <http://larseighner.com/usenet@larseigh ner.com
War hath no fury like a noncombatant.
- Charles Edward Montague

**Hendrik Maryns** · Aug 1 '08, 02:55 PM

Re: Strange behavior with Service Side Include

Op 01-08-08 01:55 heeft Lars Eighner als volgt van zich laten horen:

Is it being served as utf-8? (and you do
know that meta http-equiv is useless, don't you? -- well, not entirely
useless, but has no effect whatever on how the document is served.)

No, I didnâ€™t know that, mind pointing me to an explanation?

Cheers, H.

**Lars Eighner** · Aug 1 '08, 03:35 PM

Re: Strange behavior with Service Side Include

In our last episode,
<4893228d$1@new s.arcor-ip.de>,
the lovely and talented Hendrik Maryns
broadcast on comp.infosystem s.www.authoring.html:

Op 01-08-08 01:55 heeft Lars Eighner als volgt van zich laten horen:

>Is it being served as utf-8? (and you do
>know that meta http-equiv is useless, don't you? -- well, not entirely
>useless, but has no effect whatever on how the document is served.)

No, I didn?t know that, mind pointing me to an explanation?

I don't know what you mean by an explanation. The meta http-equiv
tag is useless for determining how a document is served by a server.
The server does not get any information from it, and when the document
comes from a server, neither does the client. It is supposed to help
a client when reading the document as a file (no server involved) by
supplying information that the server would supply if the document were
served. You can't change a served document's mime type or character set
with meta http-equiv because when the document is served that information
is in the http headers, and by the time the meta tag is sent, that ship has
sailed.

--
Lars Eighner <http://larseighner.com/usenet@larseigh ner.com
That was Zen; this is Tao.

**silverbob** · Aug 1 '08, 04:05 PM

Re: Strange behavior with Service Side Include

On Jul 31, 4:55 pm, Lars Eighner <use...@larseig hner.comwrote:

In our last episode,
<03fc3a18-cdb8-44a0-92d9-978d816e2...@a2 1g2000prf.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:
>
>
>

On Jul 31, 3:30 pm, Lars Eighner <use...@larseig hner.comwrote:

In our last episode,
<f3886e1a-8130-4411-a4aa-b8ca90fe6...@w3 9g2000prb.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

>

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

>

I went to the Symark site, and poking around a little, I did not find this
exact footer. Nonetheless, let us reason together. It cannot possibly be
that you use SSI, because SSI is seamless to the browser. It must be that
the SSI text is not *exactly* like the previous script generated text.

>

You can copy and paste the SSI text into a test document to prove that
SSI is not at fault (which is theoretically impossible anyway, but some
people still need proof that water is wet). So then you have to compare the
served SSI document (i.e. view source) with the script generated source
until you discover what is different.

>

In particular, some versions of IE are known to not handle some whitespace
(especially newlines) between tags properly. You must make the SSI agree
*exactly* with the script generated text --- including spaces and newlines,
even where they shouldn't count --- to expect consistent results in IE.
A quick examination reveals that the SSI text is not exactly the same
as the script text in reguard to spaces and newlines.

>

--
Lars Eighner <http://larseighner.com/use...@larseigh ner.com
War on Terrorism: Bad News from the Sanity Front
"There's one thing ... that I do like about Rumsfeld, he's just a little bit
crazy, OK"? --Thomas Friedman, _The New York Times_

I just reformatted the HTML so that it is exactly like the javascript
text file (minus the "document.write "). It made no difference as I
would expect because HTML does not care how its formatted.
Then, I replaced the SSI call with the exact code being used in the
SSI file, and the footers display differently. Take a look:
http://www.symark.com/test6.html(This is the SSI version)
http://www.symark.com/test7.html(This is the same SSI HTML but
embedded in the page)
Remember. This is in IE.
BTW, when I view the page source, I see a little dot or something
preceding the SSI inserted code. Is this typical?

>
No. SSI is seamless to client. However there are/is some nonsense
characters after an few more tabs (than in test7). However the same
characters appear in several other places, so I assume it is some utf-8
dingbat, intentional or otherwise. Anyway, this appears to be the only
utf-8 that is in the document. Is it being served as utf-8? (and you do
know that meta http-equiv is useless, don't you? -- well, not entirely
useless, but has no effect whatever on how the document is served.)
Is the text for the SSI being saved as utf-8?
>
--
Lars Eighner <http://larseighner.com/use...@larseigh ner.com
War hath no fury like a noncombatant.
- Charles Edward Montague

I don't want this thread to take off in a new direction, but to
address the meta http-equiv issue, when I save the document as HTML
encoding UTF-8 in my editor (MS Expression Web), it puts <meta http-
equiv="Content-Type" content="text/html; charset=utf-8"in the <head>
area.

- Bob

**Lars Eighner** · Aug 1 '08, 05:05 PM

Re: Strange behavior with Service Side Include

In our last episode,
<c23d9a46-474b-476d-9773-ffbc241a2de3@t1 g2000pra.google groups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

On Jul 31, 4:55 pm, Lars Eighner <use...@larseig hner.comwrote:

>Is it being served as utf-8? (and you do
>know that meta http-equiv is useless, don't you? -- well, not entirely
>useless, but has no effect whatever on how the document is served.)
>Is the text for the SSI being saved as utf-8?

I don't want this thread to take off in a new direction, but to
address the meta http-equiv issue, when I save the document as HTML
encoding UTF-8 in my editor (MS Expression Web), it puts <meta http-
equiv="Content-Type" content="text/html; charset=utf-8"in the <head>
area.

The meta http-equiv tag is harmless and may be helpful when the document is
viewed as a file. But it is useless when the document is served. The harm
is that the meta tag might mislead you to think it is enough for a served
document. It isn't. If you don't know the defaults for your server for
sure, you need to AddType *and* AddCharset in your .htaccess .

As I have said elsewhere, the mime type and charset need to be in the http
headers and by the time the meta tag is sent that ship has sailed.

--
Lars Eighner <http://larseighner.com/usenet@larseigh ner.com
If it wasn't for muscle spasms, I wouldn't get any exercise at all.

**silverbob** · Aug 1 '08, 06:45 PM

Re: Strange behavior with Service Side Include

I finally found a simple solution. This page described my issue,
http://www.w3.org/International/questions/qa-utf8-bom.
By opening my include files in Notepad, changing the encoding from
UTF-8 to ANSI, and resaving, I was able to eliminate the problem.

- Bob

**Ben Bacarisse** · Aug 1 '08, 06:45 PM

Re: Strange behavior with Service Side Include

silverbob <bsilverstein@s ymark.comwrites :

I finally found a simple solution. This page described my issue,
http://www.w3.org/International/questions/qa-utf8-bom.
By opening my include files in Notepad, changing the encoding from
UTF-8 to ANSI, and resaving, I was able to eliminate the problem.

Our posts crossed. Before I noticed you'd removed the U+FEFFs I was
going to say that they are often added by Windows programs to indicate
a Unicode file (they have a particular role in UTF-16 files, but any
Unicode encoding can have them added).

--
Ben.

Strange behavior with Service Side Include

Strange behavior with Service Side Include

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment