反爬虫之有个操作也许可以检测aiohttp、httpx，requests也尴尬？

前言

最近行业市场不太景气啊，趁着有时间多学学吧，武装自己，等机会
刚好，发现一个很6的东西。这个问题是在差不多半个月前，群友 @十一 发现的，然后在群里跟大家讨论。

这个网站，请求的时候，requests正常：

原始的curl也可以：

aiohttp，直接报错

httpx，也直接报错：

不过httpx的报错要明显点，这就进入了有意思的环节

分析

看到这里，估计就有朋友开始冷笑了：搞爬虫大部分不都用requests的吗，谁会用httpx和aiohttp这些啊，感觉这个是不是没啥用啊。
别急，朋友，在文章的下面会说这个，当然如果你赶时间或者觉得没啥意思，那就没必要浪费时间继续看了

1.httpx

拿着上面的报错，去网上搜，找到如下issues:

https://github.com/encode/httpx/issues/1561

https://github.com/encode/httpx/issues/1363

看完里面各位大佬的一顿分析，说是hyper库的问题：

然后hyper库的开发者，如下链接回复：

Should we support looser header name validation? · Issue #113 · python-hyper/h11 · GitHub

大概意思是这个不是一个问题，而是http请求的严格性判断问题，请求头的协议，按国际标准，是不能出现 “[Cache-Control]” 这种带有特殊符号作为响应头的键名的，所以报错
而requests却可以，或许是因为requests的校验不严格，直接就放过了：

而，浏览器访问也是可以的：

那么我个人就有理由认为

这是一个bug，httpx和aiohttp都存在的bug

 

httpx的作者，对这个问题那段时间确实在尝试解决，github机器人都想关闭了，httpx作者还不想放弃：

且至今没解决，遇到的人还不少，至少，上个月都还有人在说这个问题

　　

卧槽，这时间，上周都还有人在问啊：

其中也有说解决办法，看到有个老哥说改h11的源码，改成这样：

但是报错依然在

另外有个老哥说了这个方法：

h11.readers.header_field_re = re.compile(b"(?P<field_name>[-!#$%&'*+.^`/|~0-9a-zA-Z]+):[ \t](?P<field_value>([^\\x00\\s]+(?:[ \t]+[^\\x00\\s]+))?)[ \t]*")

我把这个代码直接放我代码里，报错了，根本没有这个属性

经过一顿查阅，他换了个属性名，是这个：

import h11from h11 import _readersimport re

h11._readers.header_field_re = re.compile(b"(?P<field_name>[-!#$%&'*+.^`/|~0-9a-zA-Z]+):[ \t](?P<field_value>([^\\x00\\s]+(?:[ \t]+[^\\x00\\s]+))?)[ \t]*")

　　

但是我试了，换成了新的报错：

也许是正则表达式写的不完美：