websocket 中 request-line 中的URI编码问题

文章讲述了作者在处理WebSocket请求时遇到的问题,Nginx误判了使用URI编码的请求,导致400错误。通过调试发现,尽管RFC6455允许URI编码,但实践中许多软件忽视了这一点,正确的处理是忽略编码并成功转发请求。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

首先,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编码,但是实际上,很多软件并没有重视这个问题。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值