Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
If it's "http:" it is going to be server side.
Adecot, your problem is entirely within the IIS configuration. Check the IIS log files for the cause of the 404 error.
The possible causes that spring quickest to mind are:
Missing or incorrect handler definition for ".kix" files.
The associated interpreter (kix32.exe) is not available on the expected path.
An error running the script has caused IIS to output a "helpful" error message.
You might do better asking the question of an IIS board, but before you do that ensure that you have verbose logging switched on in IIS and check the log files.
thanks a lot but i got the answer. I was speaking of client execution but the problem was indeed the iis config. In iis6 you have to allow explicitely the mime type so i defined a type .kix, kix file in the iis config. That works
Quote: If it's "http:" it is going to be server side.
Not really correct. It could be server-side of the .KIX extension if it is associated with a server-side execution when called, much like the .ASP configuration. It could also be a cleint-side execution that when pulling a .KIX page from the http:// address triggers the execution of a client-side KiXtart process similar to loading .PDF files into a browser.
_________________________
There are two types of vessels, submarines and targets.
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Quote:
Quote: If it's "http:" it is going to be server side.
Not really correct. It could be server-side of the .KIX extension if it is associated with a server-side execution when called, much like the .ASP configuration. It could also be a cleint-side execution that when pulling a .KIX page from the http:// address triggers the execution of a client-side KiXtart process similar to loading .PDF files into a browser.
Damnit, as soon as I posted that I had second thoughts and removed the opening comment - the edited copy didn't make it to the board
