Configuration Options for XML Web Services Created Using ASP.NET
This topic is specific to a legacy technology. XML Web services and XML Web service clients should now be created using Windows Communication Foundation.
Configuration of Web services follows the same model used by all ASP.NET Web applications. The ASP.NET configuration is an XML-based text file configuration architecture, which is both powerful and extensible. A configuration file is simply a set of XML elements that represents the configuration options for a specific technical feature of the Microsoft .NET Framework. In the case of Web services, the configuration options appear within the webServices XML element of a configuration file. For a complete list of the configuration options available to Web services, see the <webServices> Element.
Configuring Messaging Protocols and Service Help Page
The messaging protocols and service help page for Web services are configurable in the <protocols> Element XML element beneath the <webServices> Element of configuration files. Configuration is done by adding <add> Element for <protocols> and <remove> Element for <protocols> for each setting, which specify whether the setting is available for the scope of the configuration file. The add element explicitly adds support for that setting for the scope of the configuration file, whereas the remove element removes support added higher up in the configuration hierarchy. For instance, a protocol setting can be added at the machine level with an add element in the Machine.config file and then removed for a Web application with a remove element in a Web.config file. The following is the syntax for the add and remove elements:
<{add|remove} name="protocol name" />
The name attribute of the add and remove elements has the following options:
| Setting | Description |
|---|---|
HttpSoap |
Controls support of the SOAP over HTTP protocol for Web services. Installation adds support by default. |
HttpGet |
Controls support of the HTTP-GET protocol for Web services. Installation does not add support by default. |
HttpPost |
Controls support of the HTTP-POST protocol for Web services regardless of the request origination. Installation does not add support by default. |
HttpPostLocalhost |
Controls support of the HTTP-POST protocol for Web services when the request originates from the local machine. If HttpPost is added to the current configuration, then this setting has no effect. Installation adds support by default. |
Documentation |
Specifies whether a service help page is displayed when a user navigates to the URL for a Web service without any parameters in a browser. Installation adds support by default. Configuring the Documentation protocol is further described later in this topic. |
Note
The .NET Framework version 1.0 supports the HttpSoap, HttpGet, HttpPost, and Documentation settings and all are enabled at the machine level by default.
Configuring the Documentation Protocol
Navigating to the URL for the Web service without any parameters in a Web browser allows a client to view the service help page for the Web service, if the service is configured to do so. The service help page contains, by default, human readable information about how to communicate with the Web service and the Web service methods it exposes.
Because the service help page is simply an ASP.NET Web Form, it can be replaced or modified to include items such as a company logo. The file name for the service help page is specified in the <wsdlHelpGenerator> Element of a configuration file with a default setting of DefaultWsdlHelpGenerator.aspx specified in the Machine.config file.
The service help page is only displayed for Web services within the scope of a configuration file that has the Documentation protocol specified within the <protocols> Element. By default, the Documentation protocol is specified in the Machine.config file. See How to: Disable the Service Help Page for a Web Service.
Security
Before enabling the HTTP-GET or HTTP-POST protocols for a Web service, you should be aware that doing so might expose it to inadvertent invocation. For example, an unsuspecting user could receive e-mail with a link in it that, when clicked, invokes the Web service on behalf of the user using parameters supplied in the e-mail. You should consider whether such invocations might be harmful before enabling the HTTP-GET or HTTP-POST protocols.
See Also
Tasks
How to: Disable Protocol Support for Web Services
How to: Disable the Service Help Page for a Web Service
How to: Enable Discovery for XML Web Services