He says about the message handlers "...you can use them to modify the request or the response or to stop the request and immediately return a response...". I'm confused with the "modify the response" sentence. Does
it mean that the message handler should be invoked on the incomming request and on the outgoing response, once the service has executed ?

I found that only message handlers are invoked on the incomming request. Something like the RequestInterceptors from the WCF Starter Kit stack.

Not exactly. Message handlers run in a Russian doll model. That means each handler calls to the next inner handler. Once it gets to the last handler, then the service is invoked. After the service invocation, the handlers unwind thus allowing code to run
after the reponse comes back from the service.

Here's a link to an ETAG handler that shows this in action. It inspects the request, in some cases swallows the request and immediately returns a response (if an If-NoneMatch header / If-Match header was sent and
the ETAG is still valid) in other cases it calls to the next handler (using SendAsync) allowing the request to flow through, inspecting the response on the way out and injecting an ETAG.

Thank you Glenn for this exemple. Now it's clearer for me. I have another question about message handlers. As registration of message handlers matters it's a developper responsibility to register them in a good order passing innerHandlers in order to have
a russian doll model. Do you have an exemple or use case (could be a short description instead of code) where several message handlers are invoked to process the request or response. Thanks in advance.

Yeah you need to control the order. The example I gave you there was an ETag handler. In our contact manager however we have a
UriExtension handler which takes an extension like .xml and maps it to an accept header of application/xml while also rewriting the incoming url so it does not have the extension. I want the ETag handler to run before it. If I run the ETag handler
AFTER that handler it will be problematic because it will be generating an ETag based on the URI without the extension, which with my current strategy is wrong as it would result in contact/1.xml and contact/1.json having the same ETag.

Now you could make the ETag logic ALSO look at the accept header in which case not having the extension would be fine, but that's besides the point.

Another example would be a security handler. If a resource is protected, then I'll want to run that handler first before I run any otehr handlers.