Http header data structure about flare HOT 13 CLOSED

这个Remove有点丑陋...

from flare.

hmm，deque我好像知道为什么了，vector会扩容，导致之前的string被释放

from flare.

是说把headers存成map吗？这个不行，headers里面可以有重复的key，解析/序列化的时候都需要保留

from flare.

是说把headers存成map吗？这个不行，headers里面可以有重复的key，解析/序列化的时候都需要保留

重复的key吗?有点奇怪，那Set函数的定义是修改最后一个key?

from flare.

对于不存在或者只出现了一次的，set行为是明确的，如果已经重复了，flare的实现的话行为没定义（而且也不好定义）。这种情况下一般是多次调用add来添加header

from flare.

对于不存在或者只出现了一次的，set行为是明确的，如果已经重复了，flare的实现的话行为没定义（而且也不好定义）。这种情况下一般是多次调用add来添加header

呃，问题是用户在调用set的时候不一定知道有没有重复?

from flare.

理论上有这个可能，但是实际使用中其实有两类case：

1. 接收到HTTP包，这时候不知道都有哪些header，但是这种case只需要解析，通常不会需要修改别人发来的数据
2. 构造HTTP包，这时候用户清楚自己填充过哪些header

唯一的风险是作为代理转发，但是这种情况下一般既不读也不写，所以也没问题。

又读又写的case应该很少见，而且在符合rfc的范围之内，重复key的set的行为怎么定义多少都是有问题的。

这儿确实有个已知问题，就是HttpHeaders现在对于读/写共用了一套实现，所以两种情况的性能都不太好。但是想分开做的话可能得做成HttpHeaders + HttpHeadersBuilder之类的，接口比较难看，另外考虑到一般这点性能也不是很关键（不然应该直接用RPC了），所以综合考虑也就保持这样了。

from flare.

理论上有这个可能，但是实际使用中其实有两类case：

1. 接收到HTTP包，这时候不知道都有哪些header，但是这种case只需要解析，通常不会需要修改别人发来的数据
2. 构造HTTP包，这时候用户清楚自己填充过哪些header

唯一的风险是作为代理转发，但是这种情况下一般既不读也不写，所以也没问题。

又读又写的case应该很少见，而且在符合rfc的范围之内，重复key的set的行为怎么定义多少都是有问题的。

---

这儿确实有个已知问题，就是HttpHeaders现在对于读/写共用了一套实现，所以两种情况的性能都不太好。但是想分开做的话可能得做成HttpHeaders + HttpHeadersBuilder之类的，接口比较难看，另外考虑到一般这点性能也不是很关键（不然应该直接用RPC了），所以综合考虑也就保持这样了。

嗯好，我在想是否可以把相同key的value合成同一个? 一般http报文中也是在一起?而不是显示两个key-value键值对?

from flare.

不，去除重复key这个行为是non-conforming的

see also https://stackoverflow.com/questions/4371328/are-duplicate-http-response-headers-acceptable

from flare.

不，去除重复key这个行为是non-conforming的

see also https://stackoverflow.com/questions/4371328/are-duplicate-http-response-headers-acceptable

哦哦，我知道了

from flare.

有点遗憾的是Remove的时间复杂度有点高

from flare.

对。这个主要是对作为代理的case性能有影响，普通的HTTP服务端或者客户端应该不涉及remove的需求

from flare.

对。这个主要是对作为代理的case性能有影响，普通的HTTP服务端或者客户端应该不涉及remove的需求

嗯好

from flare.