如何在express中处理非UTF-8编码的url

Wil*_*unn 12 javascript iis url-encoding bing node.js

我们有一个节点js应用程序,我们最近从IIS 7(通过IIS节点)上运行到在Linux上运行(Elastic Beanstalk).自从我们切换以来,我们已经收到了很多非UTF-8网址被发送到我们的应用程序(主要来自爬虫),例如:

Bj%F6rkIIS正在转换为Björk.现在这被传递给我们的应用程序,我们的Web框架(express)最终调用了

decodeURIComponent('Bj%F6rk'); URIError: URI malformed at decodeURIComponent (native) at repl:1:1 at REPLServer.self.eval (repl.js:110:21) at repl.js:249:20 at REPLServer.self.eval (repl.js:122:7) at Interface.<anonymous> (repl.js:239:12) at Interface.emit (events.js:95:17) at Interface._onLine (readline.js:203:10) at Interface._line (readline.js:532:8) at Interface._ttyWrite (readline.js:761:14)

是否有推荐的安全方式,我们可以在发送url字符串表达之前执行与IIS相同的转换?

请记住

  1. 我们正在收到对这些编码错误的URL和的请求
  2. 有一种方法使用来解码过时的unescapejavascript函数
  3. 对这些URL的大多数请求来自Bing Bot,我们希望尽量减少对搜索排名的任何不利影响.

    • 我们真的应该为所有传入的URL做这个吗?
    • 我们应该关注是否存在任何安全或性能问题?
    • 我们是否应该担心unescape在不久的将来被移除?
    • 是否有更好/更安全的方法来解决这个问题(是的,我们确实读过上面链接的MDN文章)

Onu*_*rım 11

我们真的应该为所有传入的URL做这个吗?

不,你不应该.正在进行的请求使用非UTF8 URI组件.这不应该是你的问题.

我们应该关注是否存在任何安全或性能问题?

URI组件的编码不是安全问题.通过查询字符串或路径参数进行注入尝试.但这是另一个主题.在性能方面,每个中间件都会让您的响应花费更长的时间.但我甚至不担心.如果您想自己解码URI,那就去做吧.它只需要几毫秒.

我们是否应该关注在不久的将来被删除的情况?

其实你应该.unescape已弃用.如果你还想使用它; 只是检查它是否存在.即'unescape' in global.你也可以使用内置的替代:require('querystring').unescape()在每种情况下都不会产生相同的结果,但它不会抛出URIError.(不推荐).

为了尽量减少对搜索排名的不利影响:

确定您的快递应用程序在这些情况下返回的状态代码.它可能是500(内部服务器错误),看起来很糟糕,404(未找到)会告诉爬虫您没有查询结果(可能不是这样).

在这些情况下,我建议您通过返回客户端错误(例如400(BAD REQUEST))来覆盖它,因为问题的来源是请求的格式错误的URI组件,应该是UTF-8,但事实并非如此.爬虫/机器人应该关注这一点.

// middleware for responding with BAD REQUEST
app.use(function (err, req, res, next) {
    if (err instanceof URIError) {
        res.status(400).send();
    }
});
Run Code Online (Sandbox Code Playgroud)

最重要的是,尝试返回格式错误的URI的结果会产生其他副作用.首先,你将允许一个糟糕的请求 - 不能很好:).其次,它意味着你有一个错误的URI的结果,当它们获得200 OK响应时它将被爬虫/机器人存储并且它将被传播.然后你将不得不处理更多不好的请求.

总结 ; 不解码通过unescape.Express已经尝试通过适当的解码来解码:decodeURIComponent.如果失败了,那就试试吧.