Bug 13501 - Pragma header parsing incorrectly on HttpResponseHeaders
Summary: Pragma header parsing incorrectly on HttpResponseHeaders
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: master
Hardware: PC Windows
: --- normal
Target Milestone: Untriaged
Assignee: Marek Safar
Depends on:
Reported: 2013-07-26 06:45 UTC by Andras Zoltan
Modified: 2013-07-29 08:44 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Andras Zoltan 2013-07-26 06:45:37 UTC
It would appear that the Pragma header (and possibly others) is not parsed correctly when compared side-by-side with the .Net BCL behaviour.

This has come to light in my case as my web services always return a request ID in the Pragma header - in this format:

    'Pragma: nocache,RequestID=1'

I use the requestID for bug reports so I can marry up the request activity at the server side.

In Windows Store and 'normal' .Net, this will be parsed correctly, and I'll be able to retrieve the RequestID value from an HttpResponseMessage as follows:

    var val = msg.Headers.Pragma.FirstOrDefault(h => "RequestID".Equals(h.Name, StringComparison.OrdinalIgnoreCase));
    //assuming not null of course
    var reqId = value.Value;

However, this is not working in the Android build of the same code because msg.Headers.Pragma will *always* be empty.  A closer look at the headers collection show that the raw value is in there (i.e. everything after the colon), but not split out into the Pragma member

I've managed to isolate an NUnit test that can be used to fix:

		public void TestHeaders()
			var m = new HttpResponseMessage();
			m.Headers.Add("Pragma", "nocache,RequestID=1");
			Assert.That(m.Headers.Pragma.Count, Is.EqualTo(2));

			var nocacheNameValue = m.Headers.Pragma
				.FirstOrDefault(nv => nv.Name.Equals("nocache"));

			var reqIdNameValue = m.Headers.Pragma
				.FirstOrDefault(nv => nv.Name.Equals("RequestID"));
			Assert.That(reqIdNameValue.Value, Is.EqualTo("1"));

For comparison, this equivalent MSTest will pass in a straight .Net 4.5 or Windows Store test project:

		public void TestHeaders()
			var m = new HttpResponseMessage();
			m.Headers.Add("Pragma", "nocache,RequestID=1");
			Assert.AreEqual(2, m.Headers.Pragma.Count);

			var nocacheNameValue = m.Headers.Pragma
				.FirstOrDefault(nv => nv.Name.Equals("nocache"));

			var reqIdNameValue = m.Headers.Pragma
				.FirstOrDefault(nv => nv.Name.Equals("RequestID"));
			Assert.AreEqual("1", reqIdNameValue.Value);

Until this is fixed, it means I will have to avoid using the Pragma member in Android code - and instead use a dictionary lookup akin to the older HttpWebResponse code.

My belief (from having a look over the mono sources) is that whatever bug the parsing has could be affecting the other header properties too.
Comment 1 Andras Zoltan 2013-07-26 06:47:36 UTC
Oh I forgot to add - the android test there will fail on the third line:

 Assert.That(m.Headers.Pragma.Count, Is.EqualTo(2));
Comment 2 Andras Zoltan 2013-07-26 08:15:33 UTC
Oops - no it doesn't break there - it breaks on the 2nd line...

m.Headers.Add("Pragma", "nocache,RequestID=1");

Saying 'Invalid Format'
Comment 3 Marek Safar 2013-07-29 08:37:18 UTC
Fixed in master and 3-2 branch
Comment 4 Andras Zoltan 2013-07-29 08:44:04 UTC
Thanks ladies and gents - looking forward to seeing this in a future release :)