Ok; admittedly, the ClientHttp configuration case is not handled by the library properly; it doesn't support streaming and, upon a streaming answer from the Server, the Silverlight runtime keeps a reading thread open, which prevents the whole process from closing until the answer has finished.
For the next release, our plans are to force the library to lean on the BrowserHttp case.

In principle, the issue may be related not only with the ClientHttp, but also with other cases in which the streaming answer is buffered.
This is because, even though the Stream-sense mechanism can overcome the problem by opening a polling session, it cannot force the closure of the streaming connection.
We will work on improving this aspect.
Anyway, our tests have always shown that, when the streaming connection is blocked by something in the middle (for instance, a proxy), the Silverlight runtime behaves differently and there is nothing preventing the process from closing.