DateParseHandling (and possibly other settings) not respected when receiving a message

[joshlang]

Hi.

JSON.NET has a horrendous terrible worst-idea-ever silly pretty bad feature whereby if a string looks like a date, it'll eat it up, change it to whatever it feels like, and spit it out in some other format (preferably one you're not expecting).

We can work around it by setting DateParseHandling = DateParseHandling.None in the serializer.

This works when SENDING an rpc call. But NOT when RECEIVING an rpc call.

Here's a minimal repo:

		class meow
		{
			public string d { get; set; }
		}
		static async Task Main(string[] args)
		{
			string s = @"Content-Length: 81

{""jsonrpc"":""2.0"",""method"":""asdf"",""params"":[{""d"":""2019-01-29T03:37:28.4433841Z""}]}";
			using (MemoryStream ms = new MemoryStream())
			{
				ms.Write(Encoding.ASCII.GetBytes(s));
				ms.Position = 0;

				JsonMessageFormatter jmf = new JsonMessageFormatter();
				jmf.JsonSerializer.DateParseHandling = DateParseHandling.None;

				HeaderDelimitedMessageHandler mf = new HeaderDelimitedMessageHandler(ms, jmf);
				JsonRpc rpc = new JsonRpc(mf);
				rpc.AddLocalRpcMethod("asdf", (Func<meow, Task>)(mmm =>
				{
					Console.WriteLine(mmm.d);
					return Task.CompletedTask;
				}));
				rpc.StartListening();
				await Task.Delay(1000);
			}
			Console.ReadKey();
		}

The "d" field should be the string "2019-01-29T03:37:28.4433841Z"
But ends up being the string "01/29/2019 03:37:28"

[AArnott]

StreamJsonRpc uses a two-step deserialization whereby we first read JTokens, then we later deserialize those JTokens with the user-provided JsonSerializer. Looking into this, it appears the date time parsing (which I agree, seems hazardous!) happens during parsing into JTokens. As this step doesn't take a settings or a JsonSerializer object, the only thing we can do is manually copy the relevant settings from the user-supplied JsonSerializer object onto their matching properties on the JsonTextReader. Tedious and vulnerable to new properties being added which we then have to copy over as well. But it's fixable. :)