.net request.GetResponse() is giving me a ProtocolViolationException when header last-modified contains string "Fri, 20 Nov 2009 15:53:16 E. Australia Standard Time" ?

Question

Hi,

Q1 - Is this a bug in .net, or is the webserver I'm using for testing ( Mongoose ) not server up the header field Last-Modified in the format it should?

• So in C# VS2008 if I make the call:
  response = (HttpWebResponse)request.GetResponse();
Console.Out.WriteLine(" - LM = " + response.LastModified);

• I get: ProtocolViolationException: The value of the date string in the header is invalid

• When I use HTTPLiveHeaders to look at the HTTP head for last-modified I see:

  Last-Modified: Fri, 20 Nov 2009 15:53:16 E. Australia Standard Time

Q2 - Any suggestions on how to handle so my unit tests which rely on using the Mongoose server won't have this issue?

Q3 - Anyone know if this is something that could happen on production internet web servers a lot? i.e. should I be assuming some webservers will give the Last-Modified field back in a different sort of format that .net will balk at?

thanks

Answer 1

Q1)

If you refer to the RFC 2616 Section 14, you'll see that the definition of the Last-Modified header is:

Last-Modified = "Last-Modified" ":" HTTP-date

HTTP-date is specified in the same RFC, section 3.

  Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
  Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
  Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 [8] (an update to RFC 822 [9]). The second format is in common use, but is based on the obsolete RFC 850 [12] date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value MUST accept all three formats (for compatibility with HTTP/1.0), though they MUST only generate the RFC 1123 format for representing HTTP-date values in header fields

Since the date in your header matches the first of these, with only the time zone looking different, you can check RFC 1123 to see if it's legal. Regarding time zones, this states.

There is a strong trend towards the use of numeric timezone indicators, and implementations SHOULD use numeric timezones instead of timezone names. However, all implementations MUST accept either notation. If timezone names are used, they MUST be exactly as defined in RFC-822.

From RFC 822 Section 5 we can see the definition of the zone:

 zone        =  "UT"  / "GMT"                ; Universal Time
                                             ; North American : UT
             /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
             /  "CST" / "CDT"                ;  Central:  - 6/ - 5
             /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
             /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
             /  1ALPHA                       ; Military: Z = UT;
                                             ;  A:-1; (J not used)
                                             ;  M:-12; N:+1; Y:+12
             / ( ("+" / "-") 4DIGIT )        ; Local differential
                                             ;  hours+min. (HHMM)

As the time zone in the header is not listed here, we can therefore conclude that it is invalid, and that the server is in fact violating the protocol, so the exception appears reasonable.

Q2)

I'm afraid I don't know how you could handle it other than putting a proxy in the way that fixes up the header to be valid, or ask the people who write/maintain the Mongoose server to fix it (or fix it yourself and submit a patch, as it's an open source project).

Q3)

I've rarely (if ever) seen a web server that .NET has had problems calling, so I don't believe this type of issue is common on the internet in general.

Answer 2

Actually, anything but GMT is invalid:

"All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception." (see RFC 2616, Section 3.3.1, Paragraph 5)