Possible to include SSI in ASP page using full URL?

[ohaya]

Hi,

We want to include some SSI in our ASP pages, but where the SSI is
located on a different server, and so we need to be able to access the
SSI using a full URL, as opposed to a local file reference or relative
URL.

The "include" apparently doesn't allow this, so I was wondering if
anyone knows away to accomplish this?

Thanks!

Jim

 

[Adrienne Boswell]

Hi,

We want to include some SSI in our ASP pages, but where the SSI is
located on a different server, and so we need to be able to access the
SSI using a full URL, as opposed to a local file reference or relative
URL.

The "include" apparently doesn't allow this, so I was wondering if
anyone knows away to accomplish this?

Thanks!

Jim

AFAIK, there is no way to do this other than XMLHTTP or maybe an Iframe
(frowned upon, however).

 

[ohaya]

AFAIK, there is no way to do this other than XMLHTTP or maybe an Iframe
(frowned upon, however).

Adrienne,

Thanks for the pointer re. XMLHttp. That *almost* did it, but
unfortunately, not quite ...

I'm doing the XMLHttp call on the server-side, in an ASP page, and I was
able to GET the SSI using XMLHttp, but, the SSI includes links for
images and for css.

The images on the final page are appearing as "red X'es".

When I did view source on the final page, it looks like it's using my
hostname as the hostname in the URLs that it's using to GET the images.

In other words, the SSI has something like:

<IMG src="/icons/brand.gif"...

but on the final page served/view source it has:

<IMG src="http://myhost/icons/brand.gif"...

I can't really tell, but I think the same thing is happening with the
references/links for the css that is in the SSI that I'm getting.

Is there a way to resolve this problem?

Maybe in my ASP, I can parse the hostname part of the image and css URLs
before doing the Response.Write?

Would that work??

Any other ideas?

Jim

 

[Bob Barrows [MVP]]

Adrienne,

Thanks for the pointer re. XMLHttp. That *almost* did it, but
unfortunately, not quite ...

I'm doing the XMLHttp call on the server-side, in an ASP page, and I
was able to GET the SSI using XMLHttp, but, the SSI includes links for
images and for css.

The images on the final page are appearing as "red X'es".

When I did view source on the final page, it looks like it's using my
hostname as the hostname in the URLs that it's using to GET the
images.

In other words, the SSI has something like:

<IMG src="/icons/brand.gif"...

but on the final page served/view source it has:

<IMG src="http://myhost/icons/brand.gif"...

I can't really tell, but I think the same thing is happening with the
references/links for the css that is in the SSI that I'm getting.

Is there a way to resolve this problem?

Maybe in my ASP, I can parse the hostname part of the image and css
URLs before doing the Response.Write?

Do you have any control over that remote page so you can change those
relative links to absolute links? If not, you will have to parse and
replace the relative links with absolute links.

 

[ohaya]

Do you have any control over that remote page so you can change those
relative links to absolute links? If not, you will have to parse and
replace the relative links with absolute links.

Hi,

We were able to, as you suggested, parse/edit the relative links into
absolute links, in our ASP code, but we're seeing some strange rendering
problems at the client side, depending on which browser is used (we have
to, unfortunately, test again IE6, Firefox, NS 7 and NS 8.1). The
problems are like things appearing in the wrong order on the browser
display.

We're *guessing* that this is because we're doing the XMLHttp calls with
the 'asynchronous' parameter, but when we tried setting that to
'synchronous', the ASP is throwing an error.

Does anyone have an example of using XMLHttp in ASP server-side, but
'synchronous'?

We understand that this would cause the XMLHttp calls to block, but if
that (asynch) is the problem, then blocking seems to be better than
having to put a bunch of different cases for different browser types and
adding additional formatting for each type.

Thanks for all of your (collective) help thus far,
Jim

 

[ohaya]

Do you have any control over that remote page so you can change those
relative links to absolute links? If not, you will have to parse and
replace the relative links with absolute links.

Rob,

Sorry, I forgot to answer your question directly. "No", we don't have
direct control over the content in the SSI. The SSI content is under
control of a different group, and is a kind of centralized resource in
our organization.

Jim

 

[Anthony Jones]

Hi,

We were able to, as you suggested, parse/edit the relative links into
absolute links, in our ASP code, but we're seeing some strange rendering
problems at the client side, depending on which browser is used (we have
to, unfortunately, test again IE6, Firefox, NS 7 and NS 8.1). The
problems are like things appearing in the wrong order on the browser
display.

We're *guessing* that this is because we're doing the XMLHttp calls with
the 'asynchronous' parameter, but when we tried setting that to
'synchronous', the ASP is throwing an error.

Does anyone have an example of using XMLHttp in ASP server-side, but
'synchronous'?

We understand that this would cause the XMLHttp calls to block, but if
that (asynch) is the problem, then blocking seems to be better than having
to put a bunch of different cases for different browser types and adding
additional formatting for each type.

Achieving an Asynchronous XmlHttp fetch in ASP code is amazing, what
language are you using server side? Can you show some code? I can't
imagine how thats possible.

This is how it ought to be done:-

Dim sInclude
Dim xhr : Set xhr = Server.CreateObject("MSXML2.ServerXMLHTTP.3.0")
xhr.Open "GET", "your external url here", False
xhr.Send

If xhr.status = 200 Then
sInclude = xhr.ResponseText
' Code here to munge links to absolutes
Else
sInclude = "some html explaining failure"
End If
xhr = Nothing

Response.Write sInclude

 

[Bob Barrows [MVP]]

Rob,

Sorry, I forgot to answer your question directly. "No", we don't have
direct control over the content in the SSI. The SSI content is under
control of a different group, and is a kind of centralized resource in
our organization.

No worries: I assumed that was the case given your decision to parse/edit
the urls.

 

[Bob Barrows [MVP]]

We were able to, as you suggested, parse/edit the relative links into
absolute links, in our ASP code, but we're seeing some strange
rendering problems at the client side, depending on which browser is
used (we have to, unfortunately, test again IE6, Firefox, NS 7 and NS
8.1). The problems are like things appearing in the wrong order on
the browser display.

We're *guessing* that this is because we're doing the XMLHttp calls
with the 'asynchronous' parameter, but when we tried setting that to
'synchronous', the ASP is throwing an error.

Err ... what error? My crystal ball doesn't seem to be working at the moment

Does anyone have an example of using XMLHttp in ASP server-side, but
'synchronous'?

We understand that this would cause the XMLHttp calls to block, but if
that (asynch) is the problem, then blocking seems to be better than
having to put a bunch of different cases for different browser types
and adding additional formatting for each type.

Thanks for all of your (collective) help thus far,
Jim

I'm with Anthony: I've never used anything but synchronous calls in
server-side code.

 

[ohaya]

Achieving an Asynchronous XmlHttp fetch in ASP code is amazing, what
language are you using server side? Can you show some code? I can't
imagine how thats possible.

This is how it ought to be done:-

Dim sInclude
Dim xhr : Set xhr = Server.CreateObject("MSXML2.ServerXMLHTTP.3.0")
xhr.Open "GET", "your external url here", False
xhr.Send

If xhr.status = 200 Then
sInclude = xhr.ResponseText
' Code here to munge links to absolutes
Else
sInclude = "some html explaining failure"
End If
xhr = Nothing

Response.Write sInclude

Anthony, Bob, et al,

"Amazingly stupid" maybe . I misread the XMLHttp params. We do have
the 3rd param as "False", so it IS synchronous, and it's in ASP.

Sorry about that!

Having said that though, I guess that I'm even more puzzled about the
rendering problems that we're seeing with Mozilla/Firefox, Netscape 7.2,
and Netscape 8.1. We've been able to workaround the Firefox and
Netscape 7.2 problem by adding some additional "<BR>"s, but the Netscape
8.1 also required switching the rendering engine from "Firefox" to
"Internet Explorer".

I can't post the entire code, but basically we have an ASP page where we
are getting 3 SSIs, for a header, a point-of-contact section, and a footer.

We're basically using the following code (the snippet below is to get
the header.ssi. The "value" var contains the "http://<hostname>" to be
pre-pended to the URL) to get the SSIs:

<%
If value_found = True Then
Dim xml_header
Set xml_header = Server.CreateObject("Microsoft.XMLHTTP")
xml_header.Open "GET", value & "/ssi/header.ssi", False
xml_header.Send 'do the HTTP GET

Dim xyz_header
xyz_header = xml_header.responseText
Response.Write xml_header.responseText
Set xml_header = Nothing
End If
%>


We also have one <DIV> section ahead of the get for the header.ssi, two
<DIV> sections between the code that gets the header.ssi and poc.ssi,
and a <DIV> section after the get for the footer.ssi, i.e., the overall
page looks like:


- <DIV>....</DIV>

- get header.ssi

- <DIV>....</DIV>

- <DIV>....</DIV>

- get poc.ssi

- get footer.ssi

- <DIV>....</DIV>

With the code above for doing the SSI gets, and for Firefox, we were
originally seeing the poc.ssi stuff get rendered AHEAD of the footer.ssi
stuff.

We then added some code to the code that did the get for the poc.ssi, so
it instead looked like:

<%
If value_found = True Then
Dim xml_poc
Set xml_poc = Server.CreateObject("Microsoft.XMLHTTP")
xml_poc.Open "GET", value & "/ssi/poc.ssi", False
xml_poc.Send 'do the HTTP GET

'Now, replace the "/icons/" with "http:<hostname>/icons/"
Dim xyz_poc
xyz_poc = xml_poc.responseText
Response.Write xml_poc.responseText
If InStr(1, browsertype, "MSIE", 1) = 0 Then
Response.Write "<br><br><br><br>"
End If
Set xml_poc = Nothing
End If
%>

This seemed to fix the problem except for Netscape 8.1, but as I said in
my earlier post, this workaround seems a little kludgy (and somewhat
browser-specific). I'd really like to understand exactly what is
causing that rendering problem, and, if possible, come up with a more
elegant, and hopefully more reliable, solution.

Thanks,
Jim

 

[ohaya]

Anthony, Bob, et al,

"Amazingly stupid" maybe . I misread the XMLHttp params. We do have
the 3rd param as "False", so it IS synchronous, and it's in ASP.

Sorry about that!

Having said that though, I guess that I'm even more puzzled about the
rendering problems that we're seeing with Mozilla/Firefox, Netscape 7.2,
and Netscape 8.1. We've been able to workaround the Firefox and
Netscape 7.2 problem by adding some additional "<BR>"s, but the Netscape
8.1 also required switching the rendering engine from "Firefox" to
"Internet Explorer".

I can't post the entire code, but basically we have an ASP page where we
are getting 3 SSIs, for a header, a point-of-contact section, and a footer.

We're basically using the following code (the snippet below is to get
the header.ssi. The "value" var contains the "http://<hostname>" to be
pre-pended to the URL) to get the SSIs:

<%
If value_found = True Then
Dim xml_header
Set xml_header = Server.CreateObject("Microsoft.XMLHTTP")
xml_header.Open "GET", value & "/ssi/header.ssi", False
xml_header.Send 'do the HTTP GET

Dim xyz_header
xyz_header = xml_header.responseText
Response.Write xml_header.responseText
Set xml_header = Nothing
End If
%>


We also have one <DIV> section ahead of the get for the header.ssi, two
<DIV> sections between the code that gets the header.ssi and poc.ssi,
and a <DIV> section after the get for the footer.ssi, i.e., the overall
page looks like:


- <DIV>....</DIV>

- get header.ssi

- <DIV>....</DIV>

- <DIV>....</DIV>

- get poc.ssi

- get footer.ssi

- <DIV>....</DIV>

With the code above for doing the SSI gets, and for Firefox, we were
originally seeing the poc.ssi stuff get rendered AHEAD of the footer.ssi
stuff.

We then added some code to the code that did the get for the poc.ssi, so
it instead looked like:

<%
If value_found = True Then
Dim xml_poc
Set xml_poc = Server.CreateObject("Microsoft.XMLHTTP")
xml_poc.Open "GET", value & "/ssi/poc.ssi", False
xml_poc.Send 'do the HTTP GET

'Now, replace the "/icons/" with "http:<hostname>/icons/"
Dim xyz_poc
xyz_poc = xml_poc.responseText
Response.Write xml_poc.responseText
If InStr(1, browsertype, "MSIE", 1) = 0 Then
Response.Write "<br><br><br><br>"
End If
Set xml_poc = Nothing
End If
%>

This seemed to fix the problem except for Netscape 8.1, but as I said in
my earlier post, this workaround seems a little kludgy (and somewhat
browser-specific). I'd really like to understand exactly what is
causing that rendering problem, and, if possible, come up with a more
elegant, and hopefully more reliable, solution.

Thanks,
Jim

Hi,

I wanted to let you all know that I *think* that I've come up with a
workaround. What I did was add some Response.flush commands after the
Response.writes. With this change, I've tested with IE, the two
Netscape versions, and Firefox, and the pages appear to be consistent.

So, for example, instead of:

<%
If value_found = True Then
Dim xml_header
Set xml_header = Server.CreateObject("Microsoft.XMLHTTP")
xml_header.Open "GET", value & "/ssi/header.ssi", False
xml_header.Send 'do the HTTP GET

Dim xyz_header
xyz_header = xml_header.responseText
Response.Write xml_header.responseText
Set xml_header = Nothing
End If

I have:

<%
If value_found = True Then
Dim xml_header
Set xml_header = Server.CreateObject("Microsoft.XMLHTTP")
xml_header.Open "GET", value & "/ssi/header.ssi", False
xml_header.Send 'do the HTTP GET

Dim xyz_header
xyz_header = xml_header.responseText
Response.Write xml_header.responseText Response.flush
Set xml_header = Nothing
End If

Hopefully, this'll continue to be consistent.

Thanks for the responses!

Jim

 

[Anthony Jones]

ohaya wrote:

I have:


Hopefully, this'll continue to be consistent.

Response.flush is changing the timing of delivery. Ordinarily
Response.Writes just fill a local buffer and only after the script is
finished is the entire buffer sent to the client. With Response.Flush you
are sending content earlier giving the browser a chance to render what has
been sent so far. However the final HTML delivered should be the same so
the browser ought to be presenting the same result.

BTW, You should not be using Microsoft.XMLHTTP in ASP, use
MSXML2.ServerXMLHTTP.3..0 which is designed to be used in such Server based
scenarios.

 

[ohaya]

Response.flush is changing the timing of delivery. Ordinarily
Response.Writes just fill a local buffer and only after the script is
finished is the entire buffer sent to the client. With Response.Flush
you are sending content earlier giving the browser a chance to render
what has been sent so far. However the final HTML delivered should be
the same so the browser ought to be presenting the same result.

BTW, You should not be using Microsoft.XMLHTTP in ASP, use
MSXML2.ServerXMLHTTP.3..0 which is designed to be used in such Server
based scenarios.

Anthony,

Thanks. We'll take a look at MSXML2.ServerXMLHTTP.

Jim