首先，request-line组成如下：

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

在 rfc6455 规范的 5.1.2 Request-URI 中，有这样的描述：

The Request-URI is transmitted in the format specified in section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding [42], the origin server MUST decode the Request-URI in order to properly interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code.

 规范中明确说了如果请求URI使用“%HEX-HEX”编码方式，服务器要能正确解码URI，其潜在的含义是，请求头中的URI可能编码，也可能不编码，因此在解析请求头的时候，必须对此做出判断。

但是，在我之前做 nginx 1.24 websocket 反向代理的时候，发现我的请求始终无法通过 nginx 到达服务器，nginx会直接给我报错 400，开始的时候我非常不解，改了很多次nginx的配置也无法解决问题，后来想到了一个办法，将nginx的日志级别开到debug，然后再实验的时候，发现nginx 日志里面输出了一条记录

client sent invalid request while reading client request line, client: 192.168.0.1, server: , request: "GET %2F%2Ftest HTTP/1.1"

终于将问题定位到了请求行，我发现这个请求头和用浏览器唯一的区别就是URI的编码。于是，我将URI编码取消 ，再次发送请求，这次终于成功通过了nginx的反向代理。

对此，我只能说，虽然规范规定了可以用URI编码，但是实际上，很多软件并没有重视这个问题。