[Mono-bugs] [Bug 74878][Nor] Changed - [PATCH] Defining more than one formatter in remoting channel not supported

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by robertj at gmx.net.

http://bugzilla.ximian.com/show_bug.cgi?id=74878

--- shadow/74878	2005-12-03 11:30:50.000000000 -0500
+++ shadow/74878.tmp.15739	2005-12-03 16:37:57.000000000 -0500
@@ -10,13 +10,13 @@
 Component: CORLIB
 AssignedTo: lluis at ximian.com                            
 ReportedBy: alp at atoker.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
-Summary: Defining more than one formatter in remoting channel not supported
+Summary: [PATCH] Defining more than one formatter in remoting channel not supported
 
 Using this example from the remoting book:
 http://www.ingorammer.com/Book/EventsEnhanced.zip
 
 $ unzip EventsEnhanced.zip
 $ cd EventsEnhanced/Client_EventInitiator/bin/Debug
@@ -221,6 +221,35 @@
 
 
 ------- Additional Comments From robertj at gmx.net  2005-12-03 11:30 -------
 Created an attachment (id=16161)
 formatterchain2.diff
 
+
+------- Additional Comments From robertj at gmx.net  2005-12-03 16:37 -------
+I've changed the patch to gracefully deal with "null" content-types.
+
+Requests w/out a content-type will be handled as before the
+patch: the first formatter sink will handle them.
+
+If a content-type is supplied, the request will be passed
+down the sink chain until a formatter handles the request.
+
+If no formatter was willing to handle the request, the next
+non-formatter sink will choke on the missing requestMessage.
+The last formatter will catch this exception and it will
+try to deserialize the request. This assures that the client
+will receive an exception from the server.
+
+During the tests I found a bug in BinaryClientFormatterSink:
+AsyncProcessMessage was not setting the transport headers.
+This means, that asyc remoting calls never send the
+transport headers. I tested this against a multi-formatter
+.NET server and it didn't work, because as stated before,
+.NET relies on the content-type.
+
+Compatibility issues of the patches:
+
+Old mono clients won't be able to make *async* calls to new mono
+servers, but only if the new servers are configured to use
+*more then one* formatter.
+