Question

损坏的HTTP客户端通过URL中的换行符向基于Jetty的HTTP服务器发送了一些请求。 Jetty将此视为HTTP / 0.9请求，在换行符处截断URL，忽略请求标头，并发回没有标头或状态行的响应。

我认为根据spec这大多是正确的，虽然Jetty不需要CRLF，并且很乐意为GET以外的请求执行此操作。但是newer specs注意到HTTP / 0.9请求主要表示混淆的客户端。在我们的例子中，如果发送了错误消息，客户端（和我们）可以避免一些混乱的故障排除。

如何让Jetty在URL中使用换行符的请求返回错误响应？我很高兴使用Jetty级配置或webapp级代码。

Answer 1

首先，support for HTTP/0.9 has been completely removed in Jetty 9.3+。

让我们看看行为是什么......

Jetty Distribution 9.2.7.v20150116，运行demo-base：

正常的HTTP / 1.0请求：

$ printf "GET / HTTP/1.0\r\n\r\n" | nc localhost 8080
HTTP/1.1 200 OK
Set-Cookie: visited=yes
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Accept-Ranges: bytes
Content-Type: text/html
Last-Modified: Sat, 17 Jan 2015 00:25:03 GMT
Content-Length: 2773
Server: Jetty(9.2.7.v20150116)

<html xmlns=\ "http://www.w3.org/1999/xhtml\" xml:lang=\"en\">

那里有标题，看起来也像HTTP / 1.0响应标题。

正常的HTTP / 1.1请求：

$ printf "GET / HTTP/1.1\r\nHost: localhost\r\nConnection: close\r\n\r\n" | nc localhost 8080
HTTP/1.1 200 OK
Set-Cookie: visited=yes
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Accept-Ranges: bytes
Content-Type: text/html
Last-Modified: Sat, 17 Jan 2015 00:25:03 GMT
Content-Length: 2773
Connection: close
Server: Jetty(9.2.7.v20150116)

<html xmlns=\ "http://www.w3.org/1999/xhtml\" xml:lang=\"en\">

看起来也很正常。甚至包括HTTP / 1.1特定标头。

现在让我们尝试使用嵌入式CRLF的HTTP / 1.0：

 $ printf "GET /\r\nHTTP/1.0\r\n\r\n" | nc localhost 8080
 <html xmlns=\ "http://www.w3.org/1999/xhtml\" xml:lang=\"en\">

没有回复标题。

为什么会这样？

嗯，Jetty没有可以确定的HTTP版本，因此没有有效的标头集可以响应。所以它没有标题响应。令人惊讶的是，1.0之前的HTTP规范表现如何。

现在让我们试试Jetty Distribution 9.3.x，以及具有相同CRLF问题的基于演示的配置。

$ printf "GET /\r\nHTTP/1.0\r\n\r\n" | nc localhost 8080
HTTP/1.1 400 HTTP/0.9 not supported
Content-Length: 0
Connection: close
Server: Jetty(9.3.0-SNAPSHOT)

现在，在现代，随着HTTP / 2即将到来，这更有意义。

Answer 2

HttpServletRequest#getProtocol()将在Jetty 8中为HTTP / 0.9请求返回一个空字符串。因此，一个简单的过滤器可以为此类请求返回错误请求响应。

如the other answer所示，最近版本的Jetty 9不再支持HTTP / 0.9请求。

如何让Jetty返回错误响应而不是假设HTTP / 0.9请求？

2 个答案: