Send Specific Cookie in URLFetcher

使用 URLFetcher 作为网络请求的基础组件有一个优势：如果 server 的 response header 指明了 set-cookie，那么 URLFetcher 在发出下一个请求时会自动往 request header 中设置 cookie。

这为使用某些需要在请求时附带 cookie 的 API 提供了便利；但是同时也在某一些场合下导致了一些问题。

如果你需要为某个 API 请求的 request header 中携带自定义的 cookie 数据，例如 cookie: buvid=xxxx，那么，即使你在发送请求前通过 AddExtraRequestHeader() 添加了 cookie 头，你也会惊奇地发现，出去的请求并没有携带你设置的 cookie，而是只有 URLFetcher 自己设置的，服务端提供的 cookie 值。

不要问为什么这个时候要用 cookie 传递这个信息，而不是某个独有的 request header，亦或者 query-string；你永远不知道和你对接的人是一个怎样的智障；毕竟，没有谁会真的去读 RFC。

自定义 cookie 丢失的原因大概如下：

你首先设置了 cookie，然后发出请求
URLFetcher 在内部实际进行网络请求前，会设置服务端的 cookie 值（因为之前的请求存在 set-cookie）
因为 RFC 规定，一个 request header 中， cookie header line 有且仅有一个，也就是说

1 2	cookie: buvid=xxx cookie: sig=xxx

是不合法的；虽然可以通过

1	cookie: buvid=xxx; sig=xxx

来传递多个value，但是这要求 URLFetcher 在添加 cookie 时要能够 aware 到这点；很可惜，根据情况来看这点不成立

于是 URLFetcher 粗暴的替换了你设置的 cookie 值

扫了一遍代码之后，我想到一个 workaround，实践证明确实可以：

发请求前设置 URLFetcher 的 load flag，加上 LOAD_DO_NOT_SEND_COOKIE，阻止 URLFetcher 自己设置 cookie 的行为，完全由自己控制请求的 cookie。

话说用 URLFetcher 被坑了好多次（算上 chromium 其他的 lib，次数可以翻翻），还好每次都能够凭借“优秀工程师的第六感”蒙中问题的 root cause，进而化险为夷。我突然感觉自己理解了什么叫 文章本天成，妙笔偶得之。