Chrome 72 73版本 provisional headers are shown及(failed) net:ERR_INVALID_HTTP_RESPONSE问题

Chrome 72 73版本 provisional headers are shown及(failed) net:ERR_INVALID_HTTP_RESPONSE问题

Tag

#boa #post #request #response #ajax #provisional headers are shown #net:ERR_INVALID_HTTP_RESPONSE #chrome

问题描述

Chrome72 73版本浏览器登陆路由器页面，所有的post请求都没有response（提交无反应或返回failed to load），通过开发人员工具，在network面板中看到前端Request Header提示provisional headers are shown，状态码显示(failed) net:ERR_INVALID_HTTP_RESPONSE
该路由器后端Web server是boa


正常的请求和响应如下：

解决过程

1、请求被扩展程序拦截
【NO】 经验证，高版本无插件的浏览器中也同样存在问题，所以排除这种情况

2、服务器超时或未响应
【NO】 无论浏览器请求成功或失败，都可以通过wireshark抓到response包，后端相关表单接口都能被调用，可以排除

3、请求未正常发送，使用本地缓存
【NO】 原因同上，也可以排除该问题

4、提交请求触发表单提交的同时又通过ajax提交了请求
【NO】 前端表单只通过submit触发

5、跨域请求被拦截
【NO】 相关页面并没有跨域请求，且所有跨域请求均通过后端配置了Access-Control-Allow-Origin: * 字段

相关的文章或论坛所提到的可能是基本上是以上几种情况，都不是该问题所要寻找的答案。因此有了本文，给遇到同样问题的朋友一点启发。

根据转包信息和浏览器错误信息可以猜测，升级后的浏览器无法解析boa返回的response包，所以要么是浏览器本身的问题（可能是某些配置导致），要么是response包头的问题。

因为谷歌72以下版本及其它主流浏览器都可以正常收到response，我假设该版本浏览器存在问题，于是通过chrome Net Internals工具分析错误信息（事实上70+版本浏览器已经不能通过chrome://net-internals直接查看），跟踪到chrome相关源代码，依旧没有找到答案。

无意间在netgear论坛一篇帖子中发现了问题所在，原文如下：
There is an emerging issue for users of Google Chrome Browser

My NetGear Router D7000 – Nighthawk AC1900 WiFi VDSL/ADSL Modem Router
If I try to access http://192.168.0.1/ using Chrome, Chrome gives an error page.
Accoding to Googles Chromium Developers, this issue can only be solved by NetGear, so for all routers which have this issue, they will need a firmware update to solve the problem of having Nulls in the Header of the Router Setup Pages
Before commenting, please read the following discussion at Chromium Issues :

https://bugs.chromium.org/p/chromium/issues/detail?id=929170

See also the linked Duplicate issue there.
Note the usual advice has all been tried, clearing cache etc.
If I use Microsoft Edge Browser logging in to my router is not a problem. I also temporarily installed the NetGear Genie and tried logging in to the router with that … Again no issues.

But for however many people out there will be trying to login to similar routers with todays number 1 market share browser, Google Chrome, they will not be able to get access if they are running the latest Stable version of Chrome, v72 or later.

I guess not all router models will have such issues, unless they all have Nulls in their setup pages headers for some strange reason ?
But it looks like the Chromium devs are unwilling to undo this change, because Nulls can potentially cause issues.

文中也提到bugs.chromium.org里相关issues，点击链接查看。

解决方案

此时问题已经很明显了，boa响应的报文头中可能存在NULL字符，导致72+版本浏览器无法解析。

通过wireshark抓包发现唯一可能存在问题的地方如下图红框所示：

在Content-Length: 308后还要很多…，通过分析boa代码发现，原来这些…并非英文符号中的句点(.)，其实全部都是null，只是被wireshark解析为…

追踪问题很耗时，但修改问题却很简单，只需将这些null修改为其它任一非数字符号即可(如空格)。
相关boa代码如下：

Response.c中send_r_request_ok()函数

void send_r_request_ok2(request * req)
{
    req->response_status = R_REQUEST_OK;
    if (req->http_version == HTTP09)
        return;

    req_write(req, http_ver_string(req->http_version));
    req_write(req, " 200 OK" CRLF);
	print_http_headers(req);

	if(req->FileUploadAct == 1){	
	    req_write(req, "Pragma: no-cache" CRLF);
	    req_write(req, "Cache-Control: no-store" CRLF);
		req_write(req, "Expires: 0" CRLF);
		
	    print_last_modified(req);
	    print_content_type(req);
	    //put Content-Length at the end of header to make parsing happy
	    req_write(req, "Content-Length: ");
        req_write(req, simple_itoa(req->filesize));
	    req_write(req, "                      "); //reserve 22 characters long
	    req_write(req, CRLF);
	    req_write(req, CRLF);
	}
   
}

Asp_page.c中update_content_length()函数对上面函数中response header中content-Length做了修改，将正确的body length写入其中,对buffer进行操作时将上述预留的22个字符置为0x00，即NULL

memset(content_len_orig1, 0x00, orig_char_length);

因此只需修改该语句如下即可修复BUG(将0x00修改为空格字符’ ’)

memset(content_len_orig1, ‘ ’, orig_char_length);

当然了，不通的方案header中还可能存在其它null字符，或源码中所修改的函数均不同，但殊途同归，我们只需要造成该问题的原因，无论披着什么样的外衣都能追根溯源。