go 建议:在expectContinueReader中使用100-continue刷新其他标头,

umuewwlo  于 6个月前  发布在  Go
关注(0)|答案(3)|浏览(48)

在我们的http服务器上,我们希望在使用内置的go http服务器之前,向API消费者传递一个自定义的响应头。文档中指出,golang http服务器不支持发送自定义的1xx状态码,但是一旦使用expectCustomReader读取请求阅读器,golang http服务器本身会发送一个100-Continue
因此,建议如下:在将响应写入响应之前,尊重正在写入响应写入器的内容,然后将其与无论如何都会发送的100-Continue一起刷新。
我相信许多用户可以从中受益,很高兴听到您的想法(我也可以拥有这个并将其合并到代码库中)。
非常感谢。

wbgh16ku

wbgh16ku1#

我不太熟悉这段代码,但我不明白它是如何可靠地工作的。expectContinueReader是基于读取请求的,所以我不理解请求者和响应者将如何能够添加任何头信息。

pqwbnv8z

pqwbnv8z2#

嗯,如果没有制定详细的实施计划,在我看来,这里的主要问题是,在expectContinueReader的情况下,将编写头部的责任泄露给读者,这并不理想。读者在读取时调用实际连接上的写入操作:

func (ecr *expectContinueReader) Read(p []byte) (n int, err error) {
	if ecr.closed {
		return 0, ErrBodyReadAfterClose
	}
	w := ecr.resp
	if !w.wroteContinue && w.canWriteContinue.isSet() && !w.conn.hijacked() {
		w.wroteContinue = true
		w.writeContinueMu.Lock()
		if w.canWriteContinue.isSet() {
			w.conn.bufw.WriteString("HTTP/1.1 100 Continue\r\n\r\n") <--- this
			w.conn.bufw.Flush()
			w.canWriteContinue.setFalse()
		}
		w.writeContinueMu.Unlock()
	}
...

因此,本质上,如果我们可以通过专用方法代理实际响应对象上的写入操作,我们可以同时尊重写入其中的头部。唯一的问题是,这需要同步来确保在刷新到客户端之前没有新的头部被写入。如果同步是这里的绊脚石,我们可以通过这种方式获得更好的性能,但让我们首先讨论一下这是否是一个可行的解决方案。

esyap4oy

esyap4oy3#

我认为这也可能有助于更容易地实施103个早期提示。

相关问题