Http header data structure
4kangjc opened this issue · 13 comments
这个owning_strs_2_
为什么不用std::vector<std::string>
, 从代码中看, 只用到了push_back
和clear
还有就是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>>;
flare/flare/net/http/http_headers.h
Lines 161 to 167 in bb5cd22
这个Remove
有点丑陋...
flare/flare/net/http/http_headers.cc
Lines 107 to 129 in bb5cd22
如果用
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:
- 接收到HTTP包,这时候不知道都有哪些header,但是这种case只需要解析,通常不会需要修改别人发来的数据
- 构造HTTP包,这时候用户清楚自己填充过哪些header
唯一的风险是作为代理转发,但是这种情况下一般既不读也不写,所以也没问题。
又读又写的case应该很少见,而且在符合rfc的范围之内,重复key的set的行为怎么定义多少都是有问题的。
这儿确实有个已知问题,就是HttpHeaders现在对于读/写共用了一套实现,所以两种情况的性能都不太好。但是想分开做的话可能得做成HttpHeaders + HttpHeadersBuilder之类的,接口比较难看,另外考虑到一般这点性能也不是很关键(不然应该直接用RPC了),所以综合考虑也就保持这样了。
理论上有这个可能,但是实际使用中其实有两类case:
- 接收到HTTP包,这时候不知道都有哪些header,但是这种case只需要解析,通常不会需要修改别人发来的数据
- 构造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的需求
嗯好