On 64-bit Windows 10 and IIS 10, I am trying to develop and test a native HTTP module that will act as a WebSockets handler mapping for a specific set of script files. This is all in native C++ starting with RegisterModule(). I am not using any part of ASP.NET.
When I access a URL that should invoke the handler, I receive this response:
HTTP Error 500.21 - Internal Server Error
Handler "QuadooWebSocket" has a bad module "WebSocketModule" in its module list
Detailed Error Information:
Module IIS Web Core
Notification ExecuteRequestHandler
Handler QuadooWebSocket
Error Code 0x8007000d
More Information:
IIS core does not recognize the module.
I used the IIS Manager to setup the handler mapping, and it created an entry in the applicationHost.config file.
<handlers accessPolicy="Read, Script">
<other_modules />
<add name="QuadooWebSocket" path="*.qws" verb="*" modules="WebSocketModule" scriptProcessor="E:\dev\projects\trunk\target\debug\ActiveQuadoo.dll" resourceType="File" preCondition="bitness32" />
</handlers>
Before that, I installed support for WebSockets using the "Windows Features" control panel, and it also added a line to the applicationHost.config file.
<globalModules>
<other_modules />
<add name="WebSocketModule" image="%windir%\System32\inetsrv\iiswsock.dll" />
</globalModules>
When I attach Visual Studio to w3wp.exe, none of the breakpoints in my code are resolved. RegisterModule() is not being called. DllMain() isn't even being called. My module also implements IActiveScript, and IIS does load my module for classic ASP requests.
My code is being built into a 32-bit module, and I have enable32BitAppOnWin64="true" in the applicationHost.config file. This works for the Classic ActiveScript/ASP environment, but does this setting also work when using code that is expected to be loaded via the RegisterModule() export? If that's not the issue, then are there other steps needed to enable a native HTTP module for WebSockets?
Thanks!
After nearly two years, I decided to spend the past few days working on this again, and it's finally working!
To answer the 32-bit question... Yes, IIS can run a 32-bit WebSockets handler on a 64-bit OS.
As to why it's working now... I did rerun APPCMD.EXE again, and I poked around in the configuration until it looked like this:
<globalModules>
...
<add name="WebSocketModule" image="%windir%\System32\inetsrv\iiswsock.dll" />
<add name="WebSocketModule32" image="%windir%\SysWOW64\inetsrv\iiswsock.dll" />
<add name="QuadooWebSocket" image="E:\dev\projects\trunk\target\debug\ActiveQuadoo.dll" />
</globalModules>
<handlers accessPolicy="Read, Script">
...
<add name="QuadooWebSocket" path="*.qws" verb="*" modules="WebSocketModule32" scriptProcessor="E:\dev\projects\trunk\target\debug\ActiveQuadoo.dll" resourceType="File" preCondition="bitness32" />
...
</handlers>
<location path="Default Web Site">
<system.webServer>
<handlers>
<remove name="QuadooWebSocket" />
<add name="QuadooWebSocket" path="*.qws" verb="*" modules="QuadooWebSocket" scriptProcessor="E:\dev\projects\trunk\target\debug\ActiveQuadoo.dll" resourceType="File" requireAccess="Script" preCondition="bitness32" />
</handlers>
</system.webServer>
</location>
One difference is that my handler is now registered with the WebSocketModule32 module.
I could end the answer there, but after my handler was finally loaded, there were a number of issues that I had to work out before it actually worked correctly. Some of what I've learned might be useful to others.
Since I'm handling WebSockets asynchronously, I needed to return RQ_NOTIFICATION_PENDING from OnExecuteRequestHandler(). Otherwise, IIS immediately closed the connection.
When switching to WebSockets, this was the order I ended up using:
Set the module context.
Set the response status to 101.
Load my script VM.
Write headers (e.g. Sec-WebSocket-Protocol).
Flush() asynchronously.
If Flush() does not complete immediately, then it will be completed with a call to OnAsyncCompletion(). If it does complete immediately, use the same code path that would be called from OnAsyncCompletion() and do the following:
Get the named context for IIS_WEBSOCKET.
Cast the context to an IWebSocketContext pointer.
Start the asynchronous reader loop.
Return RQ_NOTIFICATION_PENDING.
After receiving the closing event from ReadFragment(), I call IndicateCompletion(RQ_NOTIFICATION_FINISH_REQUEST) to notify IIS that I am done with the connection. Before I added that, IIS wasn't calling my handler's CleanupStoredContext() method.
I have a standard asmx service on which GET is not allowed.
If I visit the asmx http://mysite/myservice.asmx/myoperation in the browser (GET) I get a stack trace flushed to the client and I can see from fiddler it's a 500 internal system error. None of my code is being hit.
I have a requirement not to show a stack trace if the url is visited from the browser, so I'd like to redirect to a custom error page I have in place.
I have an Application_Error on the global.asax but its not kicking in in this particular instance.
Any help appreciated!
What happens if you disable GET requests via
<configuration>
<system.web>
<webServices>
<protocols>
<remove name="HttpPost"/>
<remove name="HttpGet"/>
<remove name="Documentation"/>
</protocols>
</webServices>
</system.web>
</configuration>
But default you have to issue an HTTP POST to any web method in an asp.net 2.0 web service. How do u call a web method with HTTP GET alone. In some cases I'd also want to pass arguments to an HTTP GET method. Is this possible in the context of web services?
The accepted answer does not answer the question perfectly since you need the ASP.NET AJAX extensions for the suggested decoration to work in 2.0.
The easiest alternative to support both GET and POST for a 2.0 webservice is to setup these in web.config:
<system.web>
<webServices>
<protocols>
<add name="HttpPost" />
<add name="HttpGet" />
</protocols>
</webServices>
</system.web>
[ScriptMethod(UseHttpGet = true)]
You can use the above to make the webmethod support GET
http://www.asp.net/ajax/tutorials/understanding-asp-net-ajax-web-services
I have tried to implement progress reporting using a soap extension as described at the following links:
stackoverflow
codeproject
However, my "ProgressUpdate" method is not being called, and I believe that is because I haven't got an app.config file in my Windows Mobile project to tell the web service calls to be processed by the SOAP Extension. How can do it in Windows Mobile? This is the sample config file used in the article:
<?xmlversion="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<webServices>
<soapExtensionTypes> <add
type="SoapExtensionLib.ProgressExtension, SoapExtensionLib"
priority="1" group="High" />
</soapExtensionTypes>
</webServices>
</system.web>
</configuration>
I figured out how to do this by adding a custom attribute to the method inside the generated proxy class. The custom attribute is derived from SoapExtensionAttribute.
I got the information at MSDN
Problem now is that I have to remember to add the attribute back in if I refresh the web service reference..............
My WCF serice seems to be using the computer-name instead of the domain name. When I view the MyService.svc?wsdl link it is showing my computer name.
Where do I add my domain name in the web.config? Endpoint address, baseaddress or identity?
Note: I am using SSL so it has to be https://www.example.com/myservice.svc
WCF 4.0 has solved this issue in some instances with a new config option that use Request Headers:
<behaviors>
<serviceBehaviors>
<behavior name="AutoVaultUploadBehavior">
<useRequestHeadersForMetadataAddress>
<defaultPorts>
<add scheme="https" port="443" />
</defaultPorts>
</useRequestHeadersForMetadataAddress>
For IIS7 you don't add it to web.config, but to the IIS configuration file.
First off edit the bindings for your web site so the HTTP protocol specifies a host name if you haven't already - this will ensure it gets the correct name under HTTP.
Navigate to C:\Windows\System32\inetsrv\config and open applicationHost.config
Look for the sites section. You will see something like the following
<sites>
<site name="Default Web Site" id="1">
<application path="/">
<virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:puck" />
<binding protocol="net.tcp" bindingInformation="808:*" />
<binding protocol="net.pipe" bindingInformation="*" />
<binding protocol="net.msmq" bindingInformation="localhost" />
<binding protocol="msmq.formatname" bindingInformation="localhost" />
<binding protocol="http" bindingInformation="*:80:puck.idunno.org" />
<binding protocol="http" bindingInformation="*:80:localhost" />
<binding protocol="https" bindingInformation="*:443:" />
</bindings>
</site>
....
</sites>
You can see that the bindings for the http protocol specify a host header, but https doesn't. When you're web browsing you can't use host headers over HTTPS, but WCF still uses it when generating the WSDL - if it can't find one it will fall back to the machine name.
So all you need to do is edit the HTTPS binding like so
<binding protocol="https" bindingInformation="*:443:puck" />
appending the correct FQDN to the end of the binding information. Reset IIS and WCF should get it right now.
The IIS6 solution has already been posted by darin
As stated in this link WCF is using the computer name instead of the IP address and cannot be resolved
It solved my problem, maybe because i have multiple web sites in the same host, and is very simple.
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>
To fix this problem Configure the httpGetEnabled attribute and httpsGetEnabled attribute in web.config file
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
We're using WCFExtras to change the name of the host.
WCFExtras is a small open source library that will allow you to write the following to change the host name:
<behaviors>
<endpointBehaviors>
<behavior name="xxx">
<wsdlExtensions location="http://some-hostname-visible-from-outside/path-to-a-service/service.svc" singleFile="True" />
</behavior>
...
just adding
<useRequestHeadersForMetadataAddress></useRequestHeadersForMetadataAddress> to the solved my issue.
It seems that WCF 4.0 takes care of the Headers by adding this
I was using SSL for accessing the WCF Service.
I have added solutions here, http://knowledgebaseworld.blogspot.com/2010/06/domain-name-replaced-with-machine-name.html. it should work for you all as its working fine with me on local, staging and production without doing binding on iis
None of these solutions were helpful to me. I was able to solve this with a very simple custom Service Factory.
Installing a WCF Service on a Shared Hosting Site, Revisited
Have you tried setting the host header in IIS?
Although its an old posting, here is an answer.
Under Service Behaviour --> ServiceMetaData add service url.
Please note if you do not add myService, it will throw another error.
I had this very issue with my production server. I have found various articles on the multiple host headers with IIS and WCF issue, but if you are using SSL, you cannot add a host header to the website identities within the IIS UI, you can only add them to normal HTTP identities:
However you can add SSL host headers via a command prompt script, and this solved the issue for me:
cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:<host header>"
For more information on this see this link: http://blumenthalit.net/blog/Lists/Posts/Post.aspx?ID=14
This post solved it for me. I needed to associate my domain name with my IP address and website in IIS.
http://www.codemeit.com/wcf/wcf-wsdl-xsdimport-schemalocations-link-to-local-machine-name-not-domain-name-while-hosted-in-iis.html
Thanks to Kanasz Robert.
Steps that solved my problem -
1.Produce the wsdl in the browser and save to file (by hitting .svc?wsdl from browser) save as .wsdl
Produce the xsd files by hitting url from wsdl (xsd=xsd0, etc), and save to file from browser, save as .wsdl
replace all machine name references from wsdl with domain name (or ip address) and change xsd references and save AND replace all machine name references from xsd files with domain name (or ip address)
make sure to name xsd file with .xsd extension (ie, name0.xsd, name1.xsd, name2.xsd)
copy wsdl and xsd file(s) to virtual directory
add to your web.config following lines:
<behaviors>
<serviceBehaviors>
<behavior name="MyServiceBehavior">
<serviceMetadata httpGetEnabled="true" externalMetadataLocation="http://IPorDomainName/MyServices/FileTransferService.wsdl" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>