实现方式讨论 #6
Replies: 13 comments 29 replies
-
|
我点进你主页发现你用简体中文，所以我直接在英文后面附加一段中文，这样前面那段老外看，后面那段国人看（doge） 之前的那些方案的bug是，请求稍微长一点就会导致connection was reset，因为请求内容没被服务器读完。这个bug经过这个mod不断的测试迭代，现在已经没有了。 这个mod其它文件不是重点，重点实现在 conn.go 和 conn-http-header-reader.go 里面，你可以看看。 |
Beta Was this translation helpful? Give feedback.
-
|
嗯嗯 刚刚正在看，我之前也是建了一个新库，因为golang版本更新太快 ，我又不怕错过新版特性，后来改成追加函数了 |
Beta Was this translation helpful? Give feedback.
-
|
现在这个mod即使go标准库更新了也不会出问题 |
Beta Was this translation helpful? Give feedback.
-
|
我现在把这个issue转到讨论区了 |
Beta Was this translation helpful? Give feedback.
-
|
我最初也是写个脚本实现，后来发现有bug又改了几次（然而还是有bug）。 后来我觉得那样不是很好，实现一个功能还得以管理员权限改标准库，导致不能直接使用官方的标准库过编译，这太麻烦了。 最初这个mod还是尝试一次读完所有字节，然后进行简单处理，但是这样显然还是有bug，如果我把请求切割成两个包发送，这个处理器就无法正确处理请求，还是会connection was reset。 后来我开始研究 bufio.NewBuffer ，发现原来能通过这种方法实现内容复用，于是0.2.x版本就有了。（这个版本号不是很严谨） 近期，我尝试让http异步处理，这样能在检测到时http请求时让上级立即打印日志，释放上级的部分资源缓存。 |
Beta Was this translation helpful? Give feedback.
-
|
你真是太棒了，我都没有关注到 tls.NewListener ，我也抽空看看这个，期待你的新版本 |
Beta Was this translation helpful? Give feedback.
-
|
以后如果没有bug可能不会有新版本了，现在可能已经是极限了，我想不出有什么优化空间。 |
Beta Was this translation helpful? Give feedback.
-
|
目前性能方面也不是一定没有优化空间，但是没必要继续优化了，这点性能占用还不如http标准库高，这个mod本来就是配合http标准库使用的。 如果不使用Response响应而是直接拼接字符串，性能方面可能是会好一点，但是代码会很杂乱，以前的版本用过拼接字符串的方案，现在已经弃用了。 |
Beta Was this translation helpful? Give feedback.
-
|
我又想到了一点点优化空间，下一个小版本1.0.1会改 |
Beta Was this translation helpful? Give feedback.
-
|
v1.0.1 已发布 https://github.com/bddjr/hlfhr/releases/tag/v1.0.1 |
Beta Was this translation helpful? Give feedback.
-
|
新版本进一步减少了对tls握手的性能影响，不会在tls握手时创建chhr，只会在处理http请求时创建chhr。 |
Beta Was this translation helpful? Give feedback.
-
|
你有哪里看不懂可以直接问我 |
Beta Was this translation helpful? Give feedback.
-
|
你需要请求头超过576字节的内容吗？ 我这没有这种需求 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
307状态码可以直接复制README.md里的示范，不需要任何额外修改 https://github.com/bddjr/hlfhr?tab=readme-ov-file#httponhttpsporterrorhandler // 307 Temporary Redirect
srv.HttpOnHttpsPortErrorHandler = http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
hlfhr.RedirectToHttps(w, r, 307)
}) |
Beta Was this translation helpful? Give feedback.
-
|
我觉得还是有必要较真一下，你说只需要login.html的重定向，那更不需要自定义handler，默认的302够用了。 302方法与307方法的区别是，302方法可能会导致客户端把 POST 转为 GET ，只有遇到这种问题的时候才可能需要改用307。 |
Beta Was this translation helpful? Give feedback.
-
|
我认为你还应该看一下Connection响应头是什么意思 |
Beta Was this translation helpful? Give feedback.
-
|
使用302状态码的好处是，f12抓包一眼就能看出302是服务器返回的，307是浏览器自己HSTS的。 |
Beta Was this translation helpful? Give feedback.
-
|
你可以看看 https://github.com/bddjr/hlfhr/blob/main/response.go#L66 ，这个mod实现302状态码与Location响应头重定向的方法就在这 |
Beta Was this translation helpful? Give feedback.
-
|
好的 忘了贴这张图 当时选的都是这个页面写的最佳方式。。。 |
Beta Was this translation helpful? Give feedback.
-
|
别 断章取义 啊喂！！！ |
Beta Was this translation helpful? Give feedback.
-
|
你用edit我看不到啊，我没收到邮件啊，如果不是有人叫你重新开启issue我根本不知道你改了消息 还有，请去掉除了Connection Location Content-Length Date以外的响应头，包括用于诊断的那行HSTS，它本该由浏览器生成，而不是由服务器返回。 未登录的路径重定向处理应该交给HTTPS，而不是HTTP处理，因为cookie为了安全起见设置secure标签后，HTTP读不到cookie |
Beta Was this translation helpful? Give feedback.
-
|
把这堆没用的响应头去掉行吗，特别是那行 |
Beta Was this translation helpful? Give feedback.
-
|
好 |
Beta Was this translation helpful? Give feedback.
-
|
我看了下，你写的那个实现方案是通过劫持handshakeFn实现的，在它返回错误的时候处理Write，这导致我不能完整获取请求内容，意味着不能依据请求内容响应。 你这ServeTLS后面有些行根本没必要自己弄一遍，交给标准库就可以了，还有你这名称是不是错了，应该是ListenAndServeTLS 还有，别用内网IP测试，用localhost测试出现connection was reset的概率会更高。 |
Beta Was this translation helpful? Give feedback.
-
|
说实话啊，你的实现方式还是别往issue里发了，没有任何帮助 |
Beta Was this translation helpful? Give feedback.
-
|
我也写了个简单版（不支持自定义handler） |
Beta Was this translation helpful? Give feedback.
-
|
你的实现方式有个bug：http2没有被正确的初始化，浏览器进行TLS握手成功后会使用http/1.1，这影响了传输效率。 |
Beta Was this translation helpful? Give feedback.
-
|
我用相同的方式实现，结果h2就被干没了 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
All reactions