Has anyone seen this behavior before? All the other pages on the site are working great. Not sure why these pages have decided to cause trouble.
Did you turn on a wildcard scriptmap in your virtual folder?
+++ Rick ---
I've got a site that's been running for years and I am adding some registration pages for users to sign up and pay. It works fine on my machine, but not on the production server. On the production server, the one hit turns to many. It's running in file mode and you can see that what should show as just one hit ends up being many hits. It appears that my WWWC app responds for every resource requested. So there's the initial request for the page, then one for the CSS, one for the JS, one for images, etc. And, indeed, I can look at the Chrome dev tools and it says - for instance - that the image looks like an image but is being delivered via text/html and so it does not display. Same basic message for the CSS and JS.
Has anyone seen this behavior before? All the other pages on the site are working great. Not sure why these pages have decided to cause trouble.
West Wind Technologies
Making waves on the Web
from Maui
Did you turn on a wildcard scriptmap in your virtual folder?
+++ Rick ---
I've got a site that's been running for years and I am adding some registration pages for users to sign up and pay. It works fine on my machine, but not on the production server. On the production server, the one hit turns to many. It's running in file mode and you can see that what should show as just one hit ends up being many hits. It appears that my WWWC app responds for every resource requested. So there's the initial request for the page, then one for the CSS, one for the JS, one for images, etc. And, indeed, I can look at the Chrome dev tools and it says - for instance - that the image looks like an image but is being delivered via text/html and so it does not display. Same basic message for the CSS and JS.
Has anyone seen this behavior before? All the other pages on the site are working great. Not sure why these pages have decided to cause trouble.
However, even that should not route to your handler unless you have a wild card script map that's routing to your Web Connection application.
+++ Rick ---
Don't think so. If I did, I think the other pages would be messed up, so I don't think that's the problem. It's just these new registration pages that are messed up.
Did you turn on a wildcard scriptmap in your virtual folder?
+++ Rick ---
I've got a site that's been running for years and I am adding some registration pages for users to sign up and pay. It works fine on my machine, but not on the production server. On the production server, the one hit turns to many. It's running in file mode and you can see that what should show as just one hit ends up being many hits. It appears that my WWWC app responds for every resource requested. So there's the initial request for the page, then one for the CSS, one for the JS, one for images, etc. And, indeed, I can look at the Chrome dev tools and it says - for instance - that the image looks like an image but is being delivered via text/html and so it does not display. Same basic message for the CSS and JS.
Has anyone seen this behavior before? All the other pages on the site are working great. Not sure why these pages have decided to cause trouble.
West Wind Technologies
Making waves on the Web
from Maui
On my Dev machine I have TraceVerbHandler, OptionsVerbHandler, and StaticFile with just "*" as their path when I look in the Handler Mappings applet. However, on the production server, I have those three plus WebDAV set up that way. Then I have ExtensionlessURLHandler-ISAPI-4.0_32bit and ExtensionlessURLHandler-ISAPI-4.0_64bit with their path set to "*." Do any of these control wildcards or is that set somewhere else?
As for the other issue you mention, I am using wc.dll.
Russell
Well, you either have wildcards turned on or enabled to run all requests through the Web Connection module. I suppose you're running the .NET module rather than the ISAPI extension (wc.dll)? If so there are options in the module configuration that will force all requests through the application.
However, even that should not route to your handler unless you have a wild card script map that's routing to your Web Connection application.
+++ Rick ---
Don't think so. If I did, I think the other pages would be messed up, so I don't think that's the problem. It's just these new registration pages that are messed up.
Did you turn on a wildcard scriptmap in your virtual folder?
+++ Rick ---
I've got a site that's been running for years and I am adding some registration pages for users to sign up and pay. It works fine on my machine, but not on the production server. On the production server, the one hit turns to many. It's running in file mode and you can see that what should show as just one hit ends up being many hits. It appears that my WWWC app responds for every resource requested. So there's the initial request for the page, then one for the CSS, one for the JS, one for images, etc. And, indeed, I can look at the Chrome dev tools and it says - for instance - that the image looks like an image but is being delivered via text/html and so it does not display. Same basic message for the CSS and JS.
Has anyone seen this behavior before? All the other pages on the site are working great. Not sure why these pages have decided to cause trouble.
No that sounds all right. Can you check the static file handler and make sure that it's pointing at the staticfile module and also that it's mapped to only files?
Can you post your web.config and the <system.webServer> section?
Make sure you don't have:
<modules runAllManagedModulesForAllRequests="true">
Still even that would not cause the Web Connection module to be fired for everything. The only thing that would do that if the * handler map is pointing at Web Connection? You wouldn't have played around with trying to make extensionless URLs work would you? There are a number of ways that the IIS URL Redirect module can cause this to happen.
+++ Rick ---
A little Thanksgiving slow-down on this issue . . .
On my Dev machine I have TraceVerbHandler, OptionsVerbHandler, and StaticFile with just "*" as their path when I look in the Handler Mappings applet. However, on the production server, I have those three plus WebDAV set up that way. Then I have ExtensionlessURLHandler-ISAPI-4.0_32bit and ExtensionlessURLHandler-ISAPI-4.0_64bit with their path set to "*." Do any of these control wildcards or is that set somewhere else?
As for the other issue you mention, I am using wc.dll.
Russell
Well, you either have wildcards turned on or enabled to run all requests through the Web Connection module. I suppose you're running the .NET module rather than the ISAPI extension (wc.dll)? If so there are options in the module configuration that will force all requests through the application.
However, even that should not route to your handler unless you have a wild card script map that's routing to your Web Connection application.
+++ Rick ---
Don't think so. If I did, I think the other pages would be messed up, so I don't think that's the problem. It's just these new registration pages that are messed up.
Did you turn on a wildcard scriptmap in your virtual folder?
+++ Rick ---
I've got a site that's been running for years and I am adding some registration pages for users to sign up and pay. It works fine on my machine, but not on the production server. On the production server, the one hit turns to many. It's running in file mode and you can see that what should show as just one hit ends up being many hits. It appears that my WWWC app responds for every resource requested. So there's the initial request for the page, then one for the CSS, one for the JS, one for images, etc. And, indeed, I can look at the Chrome dev tools and it says - for instance - that the image looks like an image but is being delivered via text/html and so it does not display. Same basic message for the CSS and JS.
Has anyone seen this behavior before? All the other pages on the site are working great. Not sure why these pages have decided to cause trouble.
West Wind Technologies
Making waves on the Web
from Maui
No, I was not trying to do anything with extensionless URLs.
Web.Config is . . .
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="PHP" />
<remove name="AboMapperCustom-40218" />
<remove name="AboMapperCustom-13806" />
<add name="LOCI" path="*.loc" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\LOCI\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
</handlers>
<defaultDocument>
<files>
<clear />
<add value="index.html" />
<add value="Default.htm" />
<add value="Default.asp" />
<add value="index.htm" />
<add value="iisstart.htm" />
<add value="default.aspx" />
<add value="index.php" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
No that sounds all right. Can you check the static file handler and make sure that it's pointing at the staticfile module and also that it's mapped to only files?
Can you post your web.config and the <system.webServer> section?
Make sure you don't have:
<modules runAllManagedModulesForAllRequests="true">
Still even that would not cause the Web Connection module to be fired for everything. The only thing that would do that if the * handler map is pointing at Web Connection? You wouldn't have played around with trying to make extensionless URLs work would you? There are a number of ways that the IIS URL Redirect module can cause this to happen.
+++ Rick ---
A little Thanksgiving slow-down on this issue . . .
On my Dev machine I have TraceVerbHandler, OptionsVerbHandler, and StaticFile with just "*" as their path when I look in the Handler Mappings applet. However, on the production server, I have those three plus WebDAV set up that way. Then I have ExtensionlessURLHandler-ISAPI-4.0_32bit and ExtensionlessURLHandler-ISAPI-4.0_64bit with their path set to "*." Do any of these control wildcards or is that set somewhere else?
As for the other issue you mention, I am using wc.dll.
Russell
Well, you either have wildcards turned on or enabled to run all requests through the Web Connection module. I suppose you're running the .NET module rather than the ISAPI extension (wc.dll)? If so there are options in the module configuration that will force all requests through the application.
However, even that should not route to your handler unless you have a wild card script map that's routing to your Web Connection application.
+++ Rick ---
Don't think so. If I did, I think the other pages would be messed up, so I don't think that's the problem. It's just these new registration pages that are messed up.
Did you turn on a wildcard scriptmap in your virtual folder?
+++ Rick ---
I've got a site that's been running for years and I am adding some registration pages for users to sign up and pay. It works fine on my machine, but not on the production server. On the production server, the one hit turns to many. It's running in file mode and you can see that what should show as just one hit ends up being many hits. It appears that my WWWC app responds for every resource requested. So there's the initial request for the page, then one for the CSS, one for the JS, one for images, etc. And, indeed, I can look at the Chrome dev tools and it says - for instance - that the image looks like an image but is being delivered via text/html and so it does not display. Same basic message for the CSS and JS.
Has anyone seen this behavior before? All the other pages on the site are working great. Not sure why these pages have decided to cause trouble.
Don't know. Especially with the ISAPI extension there's no way that the DLL would hook into the general IIS request processing UNLESS IT'S MAPPED somewhere for a given extension or a wild card.
Maybe there's a mapping a level higher in the IIS folder hierarchy that accidentally routes a wild card to wc.dll.
All I can tell you is that without a mapping wc.dll will not respond to requests that it's not mapped to. Otherwise Web Connection applications would kill a Web server very, very qucikly.
+++ Rick ---
When I edit the StaticFile entry, the RequestPath is "*", of course (no quotes), the Module is "StaticFileModule,DefaultDocumentModule,DirectoryListingModule" and the Executable is blank and it's invoked only when it's mapped to a file or folder.
No, I was not trying to do anything with extensionless URLs.
Web.Config is . . .
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="PHP" />
<remove name="AboMapperCustom-40218" />
<remove name="AboMapperCustom-13806" />
<add name="LOCI" path="*.loc" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\LOCI\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
</handlers>
<defaultDocument>
<files>
<clear />
<add value="index.html" />
<add value="Default.htm" />
<add value="Default.asp" />
<add value="index.htm" />
<add value="iisstart.htm" />
<add value="default.aspx" />
<add value="index.php" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
No that sounds all right. Can you check the static file handler and make sure that it's pointing at the staticfile module and also that it's mapped to only files?
Can you post your web.config and the <system.webServer> section?
Make sure you don't have:
<modules runAllManagedModulesForAllRequests="true">
Still even that would not cause the Web Connection module to be fired for everything. The only thing that would do that if the * handler map is pointing at Web Connection? You wouldn't have played around with trying to make extensionless URLs work would you? There are a number of ways that the IIS URL Redirect module can cause this to happen.
+++ Rick ---
A little Thanksgiving slow-down on this issue . . .
On my Dev machine I have TraceVerbHandler, OptionsVerbHandler, and StaticFile with just "*" as their path when I look in the Handler Mappings applet. However, on the production server, I have those three plus WebDAV set up that way. Then I have ExtensionlessURLHandler-ISAPI-4.0_32bit and ExtensionlessURLHandler-ISAPI-4.0_64bit with their path set to "*." Do any of these control wildcards or is that set somewhere else?
As for the other issue you mention, I am using wc.dll.
Russell
Well, you either have wildcards turned on or enabled to run all requests through the Web Connection module. I suppose you're running the .NET module rather than the ISAPI extension (wc.dll)? If so there are options in the module configuration that will force all requests through the application.
However, even that should not route to your handler unless you have a wild card script map that's routing to your Web Connection application.
+++ Rick ---
Don't think so. If I did, I think the other pages would be messed up, so I don't think that's the problem. It's just these new registration pages that are messed up.
Did you turn on a wildcard scriptmap in your virtual folder?
+++ Rick ---
I've got a site that's been running for years and I am adding some registration pages for users to sign up and pay. It works fine on my machine, but not on the production server. On the production server, the one hit turns to many. It's running in file mode and you can see that what should show as just one hit ends up being many hits. It appears that my WWWC app responds for every resource requested. So there's the initial request for the page, then one for the CSS, one for the JS, one for images, etc. And, indeed, I can look at the Chrome dev tools and it says - for instance - that the image looks like an image but is being delivered via text/html and so it does not display. Same basic message for the CSS and JS.
Has anyone seen this behavior before? All the other pages on the site are working great. Not sure why these pages have decided to cause trouble.
West Wind Technologies
Making waves on the Web
from Maui
Thanks for your help.
Don't know. Especially with the ISAPI extension there's no way that the DLL would hook into the general IIS request processing UNLESS IT'S MAPPED somewhere for a given extension or a wild card.
Maybe there's a mapping a level higher in the IIS folder hierarchy that accidentally routes a wild card to wc.dll.
All I can tell you is that without a mapping wc.dll will not respond to requests that it's not mapped to. Otherwise Web Connection applications would kill a Web server very, very qucikly.
+++ Rick ---
When I edit the StaticFile entry, the RequestPath is "*", of course (no quotes), the Module is "StaticFileModule,DefaultDocumentModule,DirectoryListingModule" and the Executable is blank and it's invoked only when it's mapped to a file or folder.
No, I was not trying to do anything with extensionless URLs.
Web.Config is . . .
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="PHP" />
<remove name="AboMapperCustom-40218" />
<remove name="AboMapperCustom-13806" />
<add name="LOCI" path="*.loc" verb="*" modules="IsapiModule" scriptProcessor="C:\inetpub\wwwroot\LOCI\wc.dll" resourceType="Unspecified" preCondition="bitness32" />
</handlers>
<defaultDocument>
<files>
<clear />
<add value="index.html" />
<add value="Default.htm" />
<add value="Default.asp" />
<add value="index.htm" />
<add value="iisstart.htm" />
<add value="default.aspx" />
<add value="index.php" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
No that sounds all right. Can you check the static file handler and make sure that it's pointing at the staticfile module and also that it's mapped to only files?
Can you post your web.config and the <system.webServer> section?
Make sure you don't have:
<modules runAllManagedModulesForAllRequests="true">
Still even that would not cause the Web Connection module to be fired for everything. The only thing that would do that if the * handler map is pointing at Web Connection? You wouldn't have played around with trying to make extensionless URLs work would you? There are a number of ways that the IIS URL Redirect module can cause this to happen.
+++ Rick ---
A little Thanksgiving slow-down on this issue . . .
On my Dev machine I have TraceVerbHandler, OptionsVerbHandler, and StaticFile with just "*" as their path when I look in the Handler Mappings applet. However, on the production server, I have those three plus WebDAV set up that way. Then I have ExtensionlessURLHandler-ISAPI-4.0_32bit and ExtensionlessURLHandler-ISAPI-4.0_64bit with their path set to "*." Do any of these control wildcards or is that set somewhere else?
As for the other issue you mention, I am using wc.dll.
Russell
Well, you either have wildcards turned on or enabled to run all requests through the Web Connection module. I suppose you're running the .NET module rather than the ISAPI extension (wc.dll)? If so there are options in the module configuration that will force all requests through the application.
However, even that should not route to your handler unless you have a wild card script map that's routing to your Web Connection application.
+++ Rick ---
Don't think so. If I did, I think the other pages would be messed up, so I don't think that's the problem. It's just these new registration pages that are messed up.
Did you turn on a wildcard scriptmap in your virtual folder?
+++ Rick ---
I've got a site that's been running for years and I am adding some registration pages for users to sign up and pay. It works fine on my machine, but not on the production server. On the production server, the one hit turns to many. It's running in file mode and you can see that what should show as just one hit ends up being many hits. It appears that my WWWC app responds for every resource requested. So there's the initial request for the page, then one for the CSS, one for the JS, one for images, etc. And, indeed, I can look at the Chrome dev tools and it says - for instance - that the image looks like an image but is being delivered via text/html and so it does not display. Same basic message for the CSS and JS.
Has anyone seen this behavior before? All the other pages on the site are working great. Not sure why these pages have decided to cause trouble.