HTTP GET请求的最大长度是多少？是否存在定义的响应错误,如果收到GET请求超过此长度,服务器可以/应该返回？

更新:如标签中所示,这是在Web服务API的上下文中,尽管看到浏览器限制也很有趣.

我有一些我正在写的Web服务,我想尽可能地保持RESTful.我使用在IIS/ASP.NET/SharePoint中运行的HTTPHandler来托管这些Web服务.

我的大多数服务都期望HTTP GET.我有两个只是返回一些数据(即查询)并将是幂等的,但参数可能有点复杂.它们都可以包括服务参数中的字符,这些字符至少不允许URL的PATH部分.

使用IIS,ASP.NET和SharePoint我发现URL路径中的以下字符甚至没有进入我的HttpHandler,即使Url编码(请求爆炸,我对此没有任何简单的控制) :

• %(%25)
• &(%26)
• *(%2a,但没有Url编码)
• +(%2b)
• :(%3a)
• <(%3c)

• (%3E)

以下字符使其成为我的HttpHandler,但即使Url编码,UriTemplate也无法正确处理它们:

• (%23)

• .(%2e,但没有Url编码; UriTemplate删除了"."如果是/之前的最后一个字符)
• ？(%3f)的
• /(%2f - 即使UrlEncoded,UriTemplate也因为显而易见的原因而失败)
• \(%5c)

所以,我有点彻底,但我需要在查询字符串中测试这些url编码的字符.看起来这在大多数情况下都会起作用.

在我的一个服务中,作为参数的特殊字符在语义上是查询/过滤器的一部分(实际上是搜索服务的搜索项),但在另一个中它们实际上不是查询/过滤器的一部分,所以理想情况下它们是路径而不是查询字符串.

我的问题是,最好的选择是什么？以下是我所知道的一些内容:

1. 使用HTTP GET和查询字符串. 任何可能使用特殊字符的内容都应该在查询字符串和Url Encoded上. 这是我倾向于的地方,但我担心极长的查询字符串(IE有2083限制)

2. 在路径中使用HTTP GET和base64编码.对于可能使用特殊字符的任何参数, 请使用Modified Base64 for URL,并将其作为路径的一部分(如果需要). 我试过这个并且它有效,但它有点难看.关于极长查询字符串的问题仍然存在.

3. 使用HTTP POST和邮件正文. 任何可能使用特殊字符的东西都应该在请求的正文中. 似乎是一个不错的解决方案,但帖子被理解为不被幂和(我认为)通常意味着更改(而没有变化发生在这里).

4. 使用HTTP GET和邮件正文. 任何可能使用特殊字符的东西都应该在请求的正文中.根据SO,这似乎是一个坏主意:请求正文和Roy Fielding的HTTP GET.

5. 根据请求的大小,使用#3和#1或#2的组合.

6. 其他？？？

请注意,在某些情况下,我可以更改周围的东西以防止特殊字符(我可能会这样做),但我无法在所有情况下都这样做.

关于URI长度,RFC2616 Sec3.2.1说明如下:

HTTP协议不对URI的长度设置任何先验限制.服务器必须能够处理它们所服务的任何资源的URI,并且如果它们提供可以生成这种URI的基于GET的表单,它应该能够处理无限长度的URI.如果URI长于服务器可以处理的长度,服务器应该返回414(Request-URI Too Long)状态(参见10.4.15节).

  Note: Servers ought to be cautious about depending on …