Welcome to Windows Communication Foundation (WCF)
Top Tasks :

WCF Team Bloggers

Browse by Tags

All Tags » Indigo » HTTP » Messages   (RSS)

  • Messaging Additions in Orcas, Part 4

    Today wraps up the series on detailed messaging changes in Orcas. You can get the whole series here as well as the previous high-level overview of new Orcas features I did. Messaging Additions in Orcas Messaging Additions in Orcas, Part 2 Messaging Additions in Orcas, Part 3 Now, let's go on with the list. I've got one last feature to cover and then some of the more notable bug fixes that were reported by customers. If you need one of the bug fixes, you can get them by either installing Orcas or the .NET framework 3.0 service pack. Enhancements for web programming . RSS and ATOM syndication, partial trust, JSON, AJAX, and HTTP application programming are all covered reasonably well in the high-level overview so I didn't break them out this time. We no longer make shutdown slow. It took a somewhat rare machine configuration but the various services we run for port sharing and activation could prevent the machine from shutting down until they timed out. Copying a POX message. There aren't any standard channels that buffer messages and are used with HTTP under MessageVersion.None. However, if you write a message inspector, then you need to copy the message before reading it and that now works. Starting a listener while hosted in IIS. I don't recommend starting an independent web service from inside of a web service hosted in IIS. We've made the threading work in this service-within-service case but you're still at the mercy of IIS deciding when to deactivate the outermost service. Emptier messages. When doing POX we have to surface messages even when the HTTP payload is empty so that you have an object to get your HTTP message properties from. Until now though, when we did that conversion those messages would stop reporting that they were empty. Next time: Private Data Members Read More...
  • Just the Headers

    How do I change the HTTP status code of the response that is sent back when using a one-way contract? The result of using a one-way contract is to automatically send back an empty HTTP response when the service method is called. Sending back this response is independent of executing your service code. This means that the normal method of attaching a message property to set the HTTP status code and other HTTP headers can't be applied. There is no reply channel waiting for you to set up a message with the appropriate properties. However, there is another mechanism for sending back an empty HTTP response where you do have control over the HTTP headers. When you're using the standard request-reply contract with HTTP, you can manipulate the HTTP message that gets sent back for the reply. On that message you can put an HttpResponseMessageProperty that has SuppressEntityBody set to true. SuppressEntityBody produces equivalent messages to a one-way contract that have HTTP headers but no body contents. You should think of one-way messages and empty messages as having the same appearance but different semantics during processing. The other way around the problem is to find a lower processing layer to apply your HTTP headers. If you get below the processing layer that knows about one-way messaging, then one-way messages and empty messages are not distinguishable. It is the processing layer that recognizes the one-way protocol that creates the distinction. Next time: Binary Encodings and Addressing Read More...
  • Modifying HTTP Error Codes, Part 2

    Let's pick up where we left off last time with the question… How do I modify the HTTP status code that gets sent back with a fault? It's clear that we need to plug into the fault generation process somehow, but in past articles we've only seen fault handling for channels rather than services. Is there an equivalent for FaultConverter that we can use with our service? Well, partially. There's an IErrorHandler interface that very slightly overlaps the functionality of FaultConverter, but fortunately that's exactly the part we need. IErrorHandler allows us to replace the message faults that get created by the service. We can modify the status code by attaching a message property to the fault for the HTTP response. Here's what that looks like. I'll change the normal internal server error status code to one that indicates that the service requires payment to make the method call. class HttpErrorHandler : IErrorHandler { public bool HandleError(Exception error) { return false ; } public void ProvideFault(Exception error, MessageVersion version, ref Message fault) { if (fault != null ) { HttpResponseMessageProperty properties = new HttpResponseMessageProperty(); properties.StatusCode = HttpStatusCode.PaymentRequired; fault.Properties.Add(HttpResponseMessageProperty.Name, properties); } } } Now, we need some way to attach this error handler to the service. Since this example is using IIS hosting, there are fewer points to hook in as we don't own the service host. I'll create a new server behavior attribute that attaches an IErrorHandler instance to the service. As IErrorHandler interfaces with the service dispatcher, I need to fish out the dispatchers from the service host. class ErrorBehaviorAttribute : Attribute, IServiceBehavior { Type errorHandlerType; public ErrorBehaviorAttribute(Type errorHandlerType) { this .errorHandlerType = errorHandlerType; } public void Validate(ServiceDescription description, ServiceHostBase serviceHostBase) { } public void AddBindingParameters(ServiceDescription description, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection parameters) { } public void ApplyDispatchBehavior(ServiceDescription description, ServiceHostBase serviceHostBase) { IErrorHandler errorHandler; errorHandler = (IErrorHandler)Activator.CreateInstance(errorHandlerType); foreach (ChannelDispatcherBase channelDispatcherBase in serviceHostBase.ChannelDispatchers) { ChannelDispatcher channelDispatcher = channelDispatcherBase Read More...
  • Modifying HTTP Error Codes, Part 1

    Back to errors and faults for a bit with this two part series on modifying the HTTP status code used for fault messages. First, we'll need some background. What happens at the HTTP level when a web service encounters a problem? That's a good question because it's not clear at all from programming the service what's going to happen under the covers. Let's build a service and find out. Here's the simplest web service I could think of that has a slight problem. I'll be hosting this in IIS so there's no other code needed to get going. You can imagine the configuration that goes along with this service, but I'm going to omit any discussion of that because it won't be relevant to anything we have to look at. [ServiceContract] public interface IService { [OperationContract(Action = "*" , ReplyAction = "*" )] Message Action(Message m); } public class Service : IService { public Message Action(Message m) { throw new FaultException( "!" ); } } We can cut all the crud out of the messages by using a POX binding: a text encoder with MessageVersion set to None and a normal HTTP transport. Now, we can run this service and see what happens. I'm just going to telnet to the service address so that we can easily see all of the HTTP headers. HTTP/1.1 500 Internal Server Error Content-Type: application/xml; charset=utf-8 Server: Microsoft-IIS/7.0 X-Powered-By: ASP.NET Date: Tue, 10 Jan 2007 06:25:16 GMT Connection: close Content-Length: 159 < Fault xmlns ="http://schemas.microsoft.com/ws/2005/05/envelope/none" >< Code >< Value > Sender </ Value ></ Code >< Reason >< Text xml:lang ="en-US" > ! </ Text ></ Reason ></ Fault > This shows us that our service fault exception results in an HTTP status code of 500 for the response. The body of the message is something that looks a lot like a SOAP fault, but smaller because we said we weren't going to use SOAP. Inside the fault message you can see the fault elements that we talked about in past articles, and it's clear that we can modify anything inside the fault. It's not clear though what we modify to alter the framing of the HTTP response. That brings us to the actual question for this pair of articles. How do I modify the HTTP status code that gets sent back with a fault? We'll answer that question next time, which is going to require writing a bit more code. Next time: Modifying HTTP Error Codes, Part 2 Read More...
  • Faults and HTTP

    I left HTTP error codes out of yesterday's post on zen faults because they're representative of a distinct class of out-of-band fault messages. Out-of-band faults map fault information to a transport-specific mechanism that carries the data outside of the normal message payload. Although we don't send a regulation SOAP fault message, there's still a clear concept of a message and the other side doesn't have to rely on intuition to know that a fault took place. In the case of HTTP, the first line of a response contains status information that can be used to signify an error. There is a tradeoff to using this mechanism because SOAP faults are significantly richer than HTTP status codes while HTTP status codes are much more broadly understood by devices and programs. The status codes we care about lay in the 400 and 500 ranges. Codes in the 400 range are used for client errors and codes in the 500 range are used for server errors. Code 400 represents a generic error with the client request with additional definitions for codes 401 through 417. Similarly, code 500 represents a generic error happening on the server with additional definitions for codes 501 through 505. A code 400 error would represent something like an uninterpretably mangled request message. The common code 404 (Not Found) error represents EndpointNotFound while the much less common code 415 error (Unsupported Media Type) represents an InvalidContentType for the SOAP message. A code 500 error would represent something like a catastrophic service error, such as the code for the service can't be compiled. The only other common server error is code 503 (Service Unavailable). Code 503 errors typically represent unavailability due to server load, roughly the equivalent of ServerTooBusy. Next time: Designing New Faults Read More...

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us