A few customers have tried to control their HTTP Cookie headers from a smart client (using a previously cached cookie for example). The common experience has been “I enabled AllowCookies=true, and added the cookie using HttpRequestMessageProperty.Headers.Add. But somehow my cookie didn’t get included in my request.”
This is because “allowCookies” is a somewhat unfortunate name. When setting “allowCookies=true” on your HTTP-based binding (WsHttpBinding, BasicHttpBinding, etc), what you are indicating is that you want WCF to manage the cookie headers for you. That means that WCF will create CookieContainer, associate it with any IChannelFactory that is created from the binding, and then use that CookieContainer for all outgoing HttpWebRequests. The end result of this setup is that the user has zero control over his cookies, since the CookieContainer is taking over all management (including echoing server cookies if and only if a cookie was sent in an earlier response to that factory).
To cut a long explanation short, if you want to manipulate cookies on the client, then you (somewhat unintuitively) need to ensure that allowCookies=false. In this manner, you are taking full responsibility for all cookies sent on that channel (in all cases, including capturing response cookies and echoing appropriately).