当 header Last-modified 包含“Fri, 20 Nov 2009 15:53:16 E. Australia Standard Time”时，request.GetResponse() 会给出 ProtocolViolationException。

发布于 2024-08-12 01:35:16 字数 717 浏览 3 评论 0原文

Q1 - 这是 .net 中的错误，还是我用于测试的网络服务器（ Mongoose< /a> ) 没有以应有的格式服务器上的 Last-Modified 标头字段？

所以在 C# VS2008 中如果我拨打电话：
response = (HttpWebResponse)request.GetResponse();
Console.Out.WriteLine(" - LM = " + response.LastModified);
我得到：ProtocolViolationException：标头中日期字符串的值无效
当我使用 HTTPLiveHeaders 查看上次修改的 HTTP 标头时，我看到：
Last-Modified: Fri, 20 Nov 2009 15:53:16 E. Australia Standard Time

Q2 - 关于如何处理的任何建议，以便我依赖使用 Mongoose 服务器的单元测试不会出现此问题？

Q3 - 有人知道这是否会在生产互联网 Web 服务器上经常发生吗？即我是否应该假设某些网络服务器将以 .net 会犹豫的不同格式返回“Last-Modified”字段？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

岁月静好 2024-08-19 01:35:16

实际上，除 GMT 之外的任何时间都是无效的：

“所有 HTTP 日期/时间戳都必须以格林威治标准时间 (GMT) 表示，无一例外。” （参见 RFC 2616，第 3.3.1 节，第 5 段)

回复收藏 0 原文

御弟哥哥 2024-08-19 01:35:16

Q1)

如果您参考 RFC 2616 第 14 节，您'您会看到 Last-Modified 标头的定义是：

Last-Modified = "Last-Modified" ":" HTTP 日期

HTTP-date 已指定在同一 RFC 中，第 3 节。

 1994 年 11 月 6 日星期日 08:49:37 GMT ； RFC 822，由 RFC 1123 更新
  2094 年 11 月 6 日星期日 08:49:37 GMT ； RFC 850，被 RFC 1036 废弃
  1994 年 11 月 6 日星期日 08:49:37 ; ANSI C 的 asctime() 格式
首选第一种格式
互联网标准并代表了
定义的固定长度子集
RFC 1123 [8]（RFC 822 的更新
[9]）。第二种格式是通用的
使用，但基于过时的 RFC
850 [12] 日期格式并且缺少
四位数年份。 HTTP/1.1 客户端和
解析日期值的服务器必须
接受所有三种格式（对于
与 HTTP/1.0 的兼容性），不过
他们必须只生成 RFC 1123
表示 HTTP 日期的格式
标头字段中的值

由于标头中的日期与第一个字段匹配，只有时区看起来不同，因此您可以检查 RFC 1123 看看它是否合法。关于时区，这是这样规定的。

有一种强烈的趋势
使用数字时区指示器，
和实现应该使用数字
时区而不是时区名称。
然而，所有的实现都必须
接受任一表示法。如果时区
使用名称，它们必须准确无误
按照 RFC-822 中的定义。

从RFC 822第5节我们可以看到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)

由于标头中的时区未在此处列出，因此我们可以得出结论，它是无效的，并且服务器实际上违反了协议，因此该异常看起来是合理的。

Q2）

恐怕我不知道你如何处理它，除了以修复标头有效的方式放置代理，或者要求编写/维护 Mongoose 服务器的人修复它（或修复自己修改并提交补丁，因为它是一个开源项目）。

Q3)

我很少（如果有的话）看到 .NET 调用时出现问题的 Web 服务器，所以我不认为这种类型的问题在互联网上普遍存在。

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.

回复收藏 0 原文

~没有更多了~