1. From what I understand, if you use a SSI on a site hosted on an IIS box, all the pages must be named page.ASP. Is there a way around this? Or is it something that must be set up by the Admin?
2. It also appears that the SSI included file will not show up in the source. True? False?
2B. If the included file is not in the source code, will a spider pick it up?
3. Is there an equivalent to the .htaccess in a IIS box?
Thanks,
-G
1. both .htm(l) and .asp are OK. the difference is that the html files will be served directly (with a slight exception) but the asp files are processed through the asp processor part of the server.
2. SSI files can be inserted via the asp processor or through the normal server via Frontpage Extensions. The difference is that asp files can be coded by hand, but to take advantage of the Frontpage Extensions the files must be written using Frontpage. This is the slight exception noted above.
I know a lot of poeple would argue my choice of words there so lets just all agree now that most FP extensions cause SEO problems. In fact the only one I would consider using is the include bot which is the FP equivelant of SSI.
2b. Whether using SSI or FP includes, the result is the same. A clean html or asp page is served to both visitor and spider alike. Neither will be aware of any includes.
3. dunno, this is where we yell "XOC!"
Onya
Woz
2. If your SSI is a text file, or other non-server parsed script, it will show up in the source as though it were a part of the main file.
3. I'd like to know that answer, too. :)
Thanks Evinrude, didn't know that.
Onya
Woz
If so, how detrimental to server load times is this? Or is it even noticeable?
Also, I assume the include is done the same way as with a Unix box? <!--#include virtual...
or is there something else you have to do.
I agree with Woz.
XOC!!!
Depends on the average load, and how your server is configured. On our corp. intranet with an average of ~4000 hits daily there was no noticable load time. But then, 2000 hits is miniscule compared to some sites. Plus, it's running on two servers: dual-1Gig processors with a half a gig of RAM (overkill.....) so I wasn't exactly expecting to see a performance drop when the servers where hardly maxxed to begin with.
In practice, there will be a performance hit of some kind. But again, whether it is noticable or not will depend on your average load, concurrent connections, and hardware configuration.
Also, the include is done as you expect it to be. :)
>Also, the include is done as you expect it to be.
Same way then?
I'll have to be dealing with IIS for the first time (have stayed with Linux/Apache so far) and that'll be one of the first things I'll need to know.
Also, is the SSI operable only on static HTML pages, or also on those dynamically generated?
You can use SSI on dynamically generated pages, but, in my experience, you have to place it correctly. My experience is with ASP, so it may be different with others.
For example, the following won't work:
<%
response.write "blah blah blah"
response.write "<!--#include virtual=file.html-->"
response.write "blah blah blah"
%>
But this will:
<% response.write "blah blah blah" %>
<!--#include virtual="file.html"-->
<% response.write "blah blah blah" %>
Which makes sense, though it certainly threw me for loop when I was first learning. :)
You can name the SSI file whatever you want. However, naming them with the .asp extension has a particular advantage. That is that if someone tries to look at just the SSI file, they won't see any of the <% %> code in it, because it will get processed on the server. If you named the SSI file .HTM, on the other hand, the code in it could be viewed by giving the URL of the file in the browser. For that reason, I always use the .asp extension for my SSI files. There are other ways around this, but this is the easiest way to protect the server-side code.
As evinrude noticed, SSI processing happens before the processing of the scripts. So there is no way to use code to generate a server-side include. If you need that kind of functionality, use IIS 5.0 and use Server.Transfer or Server.Execute.
The entire contents of the SSI file is placed where the
<!--#include virtual="/directory/file.asp" -->
comment appears. If the include file has HTML, that will be passed down to the client and will get indexed by spiders. If the include file contains <% %> server-side script, then it will get processed on the server and only the result will get indexed. Just do a View Source in your browser after viewing the page to see what the spider will get.
SSI works in .htm files as well as .asp files.
The equivalent of .htaccess is a series of dialogs in something called Internet Server Manager. These dialogs modify something called the metabase, which is a database of info about IIS and is similar to the Windows Registry.
There are also a set of scripts that modify the metabase to perform the equivalent of the dialogs, for automated processing. There is also something called the metabase editor for doing serious low-level repairs to the metabase, but you have to buy a separate product from Microsoft to get it.
