Tencent/flare

Http header data structure

4kangjc opened this issue · 13 comments

这个owning_strs_2_为什么不用std::vector<std::string>, 从代码中看, 只用到了push_backclear
还有就是internal::CaseInsensitiveHashMap<std::string_view, std::size_t> , 为什么不直接使用internal::CaseInsensitiveHashMap<std::string_view, std::string_view>, 感觉没有必要映射一个size_t, 再多加一个using NonowningFields = std::vector<std::pair<std::string_view, std::string_view>>;

std::deque<std::string> owning_strs_2_;
// For better lookup (which is likely to be done frequently if we're
// parsing, instead of building, headers) performance, we build this map for
// that purpose. Values are indices into `fields_`.
internal::CaseInsensitiveHashMap<std::string_view, std::size_t> header_idx_;
// Referencing either `buffer_` or `owning_strs_`.
NonowningFields fields_;

这个Remove有点丑陋...

bool HttpHeaders::Remove(std::string_view key) noexcept {
if (!TryGet(key)) {
return false;
}
header_idx_.clear();
std::size_t i = 0;
auto it = fields_.begin();
while (it != fields_.end()) {
if (internal::detail::hash_map::CaseInsensitiveEqualTo()(it->first, key)) {
it = fields_.erase(it);
} else {
if (!header_idx_.contains(it->first)) {
header_idx_[it->first] = i;
}
++i;
++it;
}
}
// We don't remove the key/value in owning_strs_2_ because it costs.
return true;
}

如果用internal::CaseInsensitiveHashMap<std::string_view, std::string_view>, 直接erase(key)就行?

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

哦哦,我知道了

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

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

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

嗯好