Inside the Standard Bindings: BasicHttp


Index for bindings in this series:

Since there isn't a lot of documentation about how the standard bindings are put together, I decided to start a series going over each of the bindings and looking at their component pieces. I'm not going to dive into all of the binding elements so that the presentation goes a little bit faster. I'll probably get back to that some time this summer and do another series that focuses on individual binding elements.

The BasicHttp binding is going to be one of the more popular out-of-the-box choices for communicating over the Internet. The primary pivot for what goes in your channel stack is going to be the method you choose for securing messages. The choices you have with BasicHttp are no security, HTTPS security, SOAP security, and HTTPS security with SOAP credentials. This is set by the Security.Mode property on the binding. Let's look at each of those in turn.

I've cut down on the number of properties presented by eliminating duplicates between the binding settings and binding element settings. For instance, the XML reader quotas can be set on either the binding or the message encoder binding element, but I'm only going to show them on the message encoder. I've also omitted most of the security credential settings because they're very messy and you hopefully won't need to change them much.

When security is None, there are two elements in the channel stack.

  1. System.ServiceModel.Channels.TextMessageEncodingBindingElement
    AddressingVersion: Addressing10 (http://www.w3.org/2005/08/addressing)
    MaxReadPoolSize: 64
    MaxWritePoolSize: 16
    ReaderQuotas:
    MaxArrayLength: 16384
    MaxBytesPerRead: 4096
    MaxDepth: 32
    MaxNameTableCharCount: 16384
    MaxStringContentLength: 8192
  2. System.ServiceModel.Channels.HttpTransportBindingElement
    AllowCookies: False
    AuthenticationScheme: Anonymous
    BypassProxyOnLocal: False
    HostNameComparisonMode: StrongWildcard
    ManualAddressing: False
    MappingMode: Soap
    MaxBufferPoolSize: 524288
    MaxBufferSize: 65536
    MaxReceivedMessageSize: 65536
    ProxyAddress:
    ProxyAuthenticationScheme: Anonymous
    Realm:
    Scheme: http
    TransferMode: Buffered
    UnsafeConnectionNtlmAuthentication: False
    UseDefaultWebProxy: True

And there are a number of loose settings on the binding not otherwise covered by these elements.

CloseTimeout: 00:01:00
EnvelopeVersion: Soap11 (http://schemas.xmlsoap.org/soap/envelope/)
Namespace: http://tempuri.org/
OpenTimeout: 00:01:00
ReceiveTimeout: 00:01:00
SendTimeout: 00:01:00
TextEncoding: System.Text.UTF8Encoding

These are the baseline settings and all of the variations are very similar so I'm not going to repeat the properties unless they're new or different.

By switching over to Transport security, you just replace the HTTP transport with an HTTPS transport.

  1. System.ServiceModel.Channels.TextMessageEncodingBindingElement
  2. System.ServiceModel.Channels.HttpsTransportBindingElement
    RequireClientCertificate: False
    Scheme: https

With Message security, you're going to have a layered channel providing security at the SOAP level but then an unsecure HTTP transport at the bottom of your channel stack. SOAP security does not protect HTTP-level information, such as headers, so those should not be considered trustworthy.

  1. System.ServiceModel.Channels.AsymmetricSecurityBindingElement
  2. System.ServiceModel.Channels.TextMessageEncodingBindingElement
  3. System.ServiceModel.Channels.HttpTransportBindingElement

The last security mode, which is TransportWithMessageCredentials security, is also called mixed-mode security. Mixed-mode security does most of the heavy lifting through transport security. You then get the minimal SOAP security on top to provide credentials at the message level.

  1. System.ServiceModel.Channels.TransportSecurityBindingElement
  2. System.ServiceModel.Channels.TextMessageEncodingBindingElement
  3. System.ServiceModel.Channels.HttpsTransportBindingElement
    RequireClientCertificate: False
    Scheme: https

Finally, you can also change the message encoder by setting the MessageEncoding property on the binding. The only other choice you have besides the default of text is MTOM. That just changes the message encoder binding element in your stack.

  1. System.ServiceModel.Channels.MtomMessageEncodingBindingElement
  2. System.ServiceModel.Channels.HttpTransportBindingElement

You'd have to build your own binding if you wanted to use any of the other message encoders.

Next time: TechEd 2006 Chalk Talk Schedule

Comments (11)

  1. The versioning of a message in WCF is a combination of the versioning of the envelope format and the…

  2. Today continues the series I started last week about the standard bindings. The previous article covered…

  3. Part 3 of the series detailing the standard bindings (Part 1 was on BasicHttp and Part 2 was on NetTcp)….

  4. Sam Gentile says:

    Only one more to go and I’ll hit the magic 100 – only took three years to get there-).  [More]

  5. The WsHttp binding is a lot like the BasicHttp binding with the Web Services knob turned up a little…

  6. The final HTTP binding that I’m covering in this series is WSFederationHttp.  Federation is the ability…

  7. I thought I’d share the binding inspector program I wrote a few months ago to explore the different settings…

  8. The versioning of a message in WCF is a combination of the versioning of the envelope format and the

  9. BasicHttpBinding, can there be security?. Yes! The point is this binding can be secured and that too

  10. Sam Gentile says:

    Only one more to go and I'll hit the magic 100 – only took three years to get there-). The Master

  11. Only one more to go and I’ll hit the magic 100 – only took three years to get there-). The Master, Mike Gunderloy (who everyone should read and I ripped off) has hit Number 900 (Congrats Mike!) and has announced a new contest Windows Vista Beta 2 has

Skip to main content