|
|
Browse by Tags
All Tags » HTTP » Transports » Indigo (RSS)
-
You may have noticed that an HTTP binding is configured with an HttpClientCredentialType whereas an HTTP binding element is configured with an AuthenticationScheme. How are these two settings related? If you want to switch between a custom binding and a standard binding for HTTP, then you need to know how to do the translation. Here's how client credentials map to authentication schemes: HttpClientCredentialType.None becomes AuthenticationSchemes.Anonymous HttpClientCredentialType.Certificate also becomes AuthenticationSchemes.Anonymous. Certificates are used with HTTPS rather than as authentication credentials on top of HTTP. This will be caught in validation if you try to use certificates with the TransportCredentialOnly security mode. HttpClientCredentialType.Basic becomes AuthenticationSchemes.Basic HttpClientCredentialType.Digest becomes AuthenticationSchemes.Digest HttpClientCredentialType.Ntlm becomes AuthenticationSchemes.Ntlm HttpClientCredentialType.Windows becomes AuthenticationSchemes.Negotiate Translation works the same way with proxy credentials and the proxy authentication scheme except that proxies don't have to worry about the issue with certificates. Next time: Get a Real XML Parser Read More...
|
-
I need to make many simultaneous HTTP calls to the same service from my client application. How do I increase the limit on the number of HTTP connections? This setting isn't available on any of the bindings or binding elements but the default limit can be set through the DefaultConnectionLimit property on System.Net.ServicePointManager. This will change the limit for every server you want to connect to. Alternatively, you can control the connection limit very granularly through configuration. < system.net > < connectionManagement > < add address ="..." maxconnection ="2" /> </ connectionManagement > </ system.net > The address can be for a particular HTTP address or for a plain machine name. Use the wildcard character * for the address to set the default connection limit through configuration. If a request can match against more than one of the configuration entries, then the most specific entry is the one that will be used. Next time: Mapping Credentials to Authentication Schemes Read More...
|
-
I've got a sessionful contract that I want to use with HTTP. How do I get the HTTP transport to produce a sessionful channel shape? The basic design principle of channels is that they produce whatever channel shape is their natural message exchange pattern. For HTTP, the natural message exchange pattern is request-reply. This means that if you want any other channel shape, then you need to apply a layered channel that changes the message exchange pattern. That is the approach regardless of whether you want to change the channel shape to one-way, duplex, or a sessionful channel. There are no built-in HTTP specific additions to create sessionful channels. We have a sample channel that demonstrates creating a session based on HTTP cookies . There are several general-purpose protocol channels that provide sessions, such as security and reliable messaging. However, this entire line of conversation tends to indicate a fundamental flaw in thinking. A session has the semantic meaning of correlating messages together according to some principle of relationship. Sessionful services use the relationship to treat the session of messages as a connected unit. The meaning of that session ought to be a more significant factor than whether some contract has been previously declared to know about sessions. If you are scrounging around to come up with any possible session to get a service working, then something is probably wrong. Next time: XML Support Read More...
|
-
Why doesn't anything happen when I try to add HTTP headers from a message encoder? The problem here is a basic issue of timing. Recall the interface contract that a message encoder has with its transport. The transport receives a message from the next channel up in the channel stack, does some processing on the message, and calls WriteMessage on the message encoder when it wants to write out the message body. The message encoder does not necessarily see all of the message content. Some message content, such as framing, is independent of the message encoding and directly handled by the transport. In fact, the message encoder may not be called at all if there is no content for it to write. HTTP headers are an example of content that is handled by the transport rather than the message encoder. The message encoding transforms the body of the message, but HTTP headers are always sent as text. In the call to WriteMessage, the message encoder does get a Message object, which has a handle to the HTTP headers. However, if you look at the format of a raw HTTP message, then you would see that the HTTP headers are completely written out before the message body is written out. When streaming an HTTP message, the headers may even be transmitted before the message body is written out. Therefore, you should guess that it's unlikely that the message encoder can do anything with the HTTP header collection because the HTTP headers may already have been transmitted. If you want to change the HTTP headers, then you should make sure that all of the changes are made before the transport is given the message. Next time: WCF Case Studies Read More...
|
-
I occasionally see people asking how they can fake the security capabilities of a binding. These questions often start off with "I'm getting an error message that a message's required protection level is not being met". Now, I'm not precisely sure why you'd want to fake the security capabilities in this case. After all, the application developer is in charge of both specifying the protection requirements of the messages and choosing what channels to use. If they're getting this error message, then it more than likely means that this helpful check has detected a problem somewhere in their design. There are a few rare reasons why you'd want to fake this, but they mainly involve transmitting over specially secured networks. However, it turns out that faking security capabilities is exactly the same as legitimately specifying the capabilities of a custom channel so I might as well explain that! Security capabilities are found by querying the channel stack with GetProperty for an instance of ISecurityCapabilities. This call should be supported on the binding element of channels that implement message or transport security. Transport channels should respond with something, even if it is to say that they don't support any kind of security. Everyone else can just delegate the call to their inner channel (which is typically what you do by default for any type you don't know about). public interface ISecurityCapabilities { ProtectionLevel SupportedRequestProtectionLevel { get; } ProtectionLevel SupportedResponseProtectionLevel { get; } bool SupportsClientAuthentication { get; } bool SupportsClientWindowsIdentity { get; } bool SupportsServerAuthentication { get; } } The fields here should be self-explanatory, you either support a particular feature or you don't, but let's look at examples from some of the existing channels. HTTP doesn't support any protection on requests and responses, neither encryption nor signing. HTTP supports client authentication when in any security mode but Anonymous. It only supports server authentication when using Negotiate security. Windows identities are supported whenever client authentication is. On the other hand, HTTPS provides both encryption and signing for both requests and responses. HTTPS always does server authentication. It supports client authentication and Windows identities whenever HTTP would plus whenever client certificates are turned on. You can quickly get a sense of the differences between HTTP and HTTPS by looking at Read More...
|
-
The HTTP transport and binding element have three settings for controlling the proxy behavior. public bool BypassProxyOnLocal { get; set; } public Uri ProxyAddress { get; set; } public bool UseDefaultWebProxy { get; set; } UseDefaultWebProxy controls whether manual proxy settings are used or whether the automatically-configured system proxy settings are used. ProxyAddress is how you manually specify the proxy. If you're using the automatically-configured proxy, then you can't also specify a manual proxy address. Finally, BypassProxyOnLocal allows you to control whether the proxy is used for destination addresses that are on your local network. Requests to any loopback adapter address or the special host name localhost are always bypassed. Even if you set BypassProxyOnLocal to false, requests to these addresses will still not go through the proxy. Unfortunately, overriding this behavior would require writing a custom instance of IWebProxy and attaching that proxy to the underlying web requests that are being made. It's more common to hit this problem during development when you're testing on a machine that doesn't have the same networking setup that the real server will have. One workaround is to install a virtual network adapter that performs loopback in software. This allows you to send requests to an address that is not classified as a loopback without having to add new hardware to your system. Next time: Registration of Base Addesses Read More...
|
-
IIS uses some inscrutable strings to configure the activatable bindings of a web site. Here's the minimum you need to interpret a binding and get started working with activation. Activation is controlled by the activationHost.config file. In the list of web sites, each site has a binding section that contains the list of supported protocols. < site name ="Default Web Site" id ="1" > < bindings > < binding protocol ="HTTP" bindingInformation ="*:80:" /> < binding protocol ="net.tcp" bindingInformation ="808:*" /> </ bindings > </ site > The format for the HTTP binding information comes from IIS. It has three parts separated by colons. The three parts are List of IP addresses to listen on (or a wildcard symbol) Port number List of host headers (or blank) The format for TCP was picked to be as similar as possible to what already existed for HTTP. We have two parts to configure, again separated by colons. There is no equivalent for the list of addresses. The two parts are Port number Host name comparison mode (blank or a wildcard symbol) Next time: Proxy Bypassing Behavior Read More...
|
-
Fault messages have their own quota sizes, allowing you to limit the amount of data you'll process in response to an error. Existing transport protocols don't know about SOAP fault messages, but some of them have their own error reporting mechanisms that we use for similar purposes. HTTP lets you send back error responses, and there is a similar quota setting for HTTP web requests that let you bound the size of the response. The point of writing this is that the translation doesn't always go smoothly between these quota systems. Our SOAP quotas are measured in bytes while the HTTP quotas need to be rounded up in size to the next largest value measured in kilobytes. Someone recognized that this means that there's a potential for integer overflow in the conversion and so handled that case specially. We take the maximum buffer size and use that to bound your maximum HTTP error size. For buffered transfers, the maximum buffer size is the same thing as the maximum received message size while for streamed transfers, the total message can span many buffered transfers. Unfortunately, the way that overflow is avoided in the computation causes the HTTP quota to not be set in that case. This means that if your maximum buffer size is within 1 KB of Int.MaxValue, the maximum error size doesn't get increased. There's a couple of solutions that you can use here. The default allowed error size is 64 KB so this bug doesn't matter at all if your error messages are smaller than this size. From a practical perspective, there isn't much difference between using Int.MaxValue or a slightly smaller value for the buffer size, so you can avoid the bug by reducing your maximum buffer size by 1025 bytes. It's also possible to directly set the default maximum error size. This is the DefaultMaximumErrorResponseLength setting of HttpWebRequest. Changing this value affects all HTTP traffic in your application, but if you know what your maximum limit is, you can set this and we won't ever use a smaller value. Next time: Reader Mail Read More...
|
|
|
|