深入Python3(十三) HTTP Web 服务

0.摘要

  简单地讲，$HTTPweb$ 服务是指以编程的方式直接使用 $http$ 操作从远程服务器发送和接收数据。如果你要从服务器获取数据，使用$httpGET$；如果你要向服务器发送新数据，使用$httpPOST$。一些更高级的$httpWeb$ 服务 $api$也允许使用$httpPUT$ 和 $httpDELETE$来创建、修改和删除数据。 换句话说，$http$ 协议中的“$verbs$ (动作)” (GET, POST, PUT 和 DELETE) 可以直接对应到应用层的操作：获取，创建，修改，删除数据。

  这个方法主要的优点是简单, 它的简单证明是受欢迎的。数据 — 通常是$xml$或$json$ — 可以事先创建好并静态的存储下来 ，或者由服务器端脚本动态生成, 并且所有主要的编程语言(当然包括 $Python$)都包含$http$ 库用于下载数据。调试也很方便; 由于$httpweb$ 服务中每一个资源都有一个唯一的地址(以$url$的形式存在), 你可以在浏览器中加载它并且立即看到原始的数据。

  $httpweb$ 服务示例:

• Google Data api 允许你同很多类型的Google 服务交互, 包括 Blogger 和 YouTube。
• Flickr Services 允许你向Flickr下载和上传图片。
• Twitter api 允许你在Twitter发布状态更新。
• …以及更多

  $Python3$ 带有两个库用于和$httpweb$ 服务交互:

• http.client 是实现了rfc 2616, http 协议的底层库.
• urllib.request 建立在http.client之上一个抽象层。 它为访问http 和 ftp 服务器提供了一个标准的api，可以自动跟随http 重定向， 并且处理了一些常见形式的http 认证。

  那么，你应该用哪个呢？两个都不用。取而代之, 你应该使用 $httplib2$,一个第三方的开源库,它比$http.client$更完整的实现了$http$协议，同时比$urllib.request$提供了更好的抽象。

  要理解为什么$httplib2$是正确的选择，你必须先了解$http$。

1.HTTP的特性

  有五个重要的特性所有的$http$客户端都应该支持。

1.1缓存

  关于$web$服务最需要了解的一点是网络访问是极端昂贵的。我并不是指“美元”和“美分”的昂贵(虽然带宽确实不是免费的)。我的意思是需要一个非常长的时间来打开一个连接，发送请求，并从远程服务器响应。 即使在最快的宽带连接上，延迟（从发送一个请求到开始在响应中获得数据所花费的时间）仍然高于您的预期。路由器的行为不端，被丢弃的数据包，中间代理服务器被攻击 — 在公共互联网上没有沉闷的时刻(never a dull moment)，并且你对此无能为力。

  $Cache-Control:max-age$ 的意思是“一个星期以内都不要来烦我。”$http$在设计时就考虑到了缓存。有这样一类的设备(叫做 “缓存代理服务器”) ，它们的唯一的任务是就是呆在你和世界的其他部分之间来最小化网络请求。你的公司或$isp$ 几乎肯定维护着这样的缓存代理服务器, 只不过你没有意识到而已。 它们的能够起到作用是因为缓存是内建在$http$协议中的。

  这里有一个缓存如何工作的具体例子。 你通过浏览器访问diveintomark.org。该网页包含一个背景图片， wearehugh.com/m.jpg。当你的浏览器下载那张图片时,服务器的返回包含了下面的$http$ 头:

  $Cache-Control$ 和 $Expires$ 头告诉浏览器(以及任何处于你和服务器之间的缓存代理服务器) 这张图片可以缓存长达一年。 一年! 如果在明年，你访问另外一个也包含这张图片的页面，你的浏览器会从缓存中加载这张图片而不会产生任何网络活动。

  等一下，情况实际上更好。比方说，你的浏览器由于某些原因将图片从本地缓存中移除了。可能是因为没有磁盘空间了或者是你清空了缓存，不管是什么理由。然而$http$ 头告诉说这个数据可以被公共缓存代理服务器缓存($Cache-Control$头中$public$关键字说明这一点)。缓存代理服务器有非常庞大的存储空间，很可能比你本地浏览器所分配的大的多。

  如果你的公司或者$isp$维护着这样一个缓存代理服务器，它很可能仍然有这张图片的缓存。 当你再次访问diveintomark.org 时, 你的浏览器会在本地缓存中查找这张图片, 它没有找到, 所以它发出一个网络请求试图从远程服务器下载这张图片。但是由于缓存代理服务器仍然有这张图片的一个副本，它将截取这个请求并从它的缓存中返回这张图片。 这意味这你的请求不会到达远程服务器; 实际上, 它根本没有离开你公司的网络。这意味着更快的下载(网络跃点变少了) 和节省你公司的花费(从外部下载的数据变少了)。

  只有当每一个角色都做按协议来做时，$http$缓存才能发挥作用。一方面，服务器需要在响应中发送正确的头。另一方面，客户端需要在第二次请求同样的数据前理解并尊重这些响应头。 代理服务器不是灵丹妙药，它们只会在客户端和服务器允许的情况下尽可能的聪明。

  $Python$的$http$库不支持缓存，而$httplib2$支持。

1.2最后修改时间的检查

  有一些数据从不改变，而另外一些则总是在变化。介于两者之间，在很多情况下数据还没变化但是将来可能会变化。 CNN.com 的供稿每隔几分钟就会更新，但我的博客的供稿可能几天或者几星期才会更新一次。在后面一种情况的时候，我不希望告诉客户端缓存我的供稿几星期，因为当我真的发表了点东西的时候，人们可能会几个星期后才能阅读到(由于他们遵循我的$cache$ 头—“几个星期内都不用检查这个供稿”)。另一方面，如果供稿没有改变我也不希望客户端每隔1小时就来检查一下!

  $http$ 对于这个问题也有一个解决方案。当你第一次请求数据时，服务器返回一个$Last-Modified$头。 顾名思义：数据最后修改的时间。diveintomark.org引用的这张背景图片包含一个$Last-Modified$头。

  如果第二(第三，第四）次请求同样一个资源，你可以在你的请求中发送一个$If-Modified-Since$头，其值为你上次从服务器返回的时间。如果从那时开始，数据已经发生过变化，服务器会忽略$If-Modified-Since$头并返回新数据和200状态码给你。否则的话，服务器将发回一个特殊的$http304$ 状态码, 它的含义是“从上次请求到现在数据没有发生过变化.” 你可以在命令行上使用$curl$来测试:

  为什么这是一个进步？因为服务器发送304时, 它没有重新发送数据。你得到的仅仅是状态码。即使你的缓存副本已经过期，最后修改时间检查保证你不会在数据没有变化的情况下重新下载它。 (额外的好处是，这个304 响应同样也包含了缓存头。代理服务器会在数据已经“过期”的情况下仍然保留数据的副本; 希望数据实际上还没有改变，并且下一个请求以304状态码返回，并更新缓存信息。)

  $Python$的$http$ 库不支持最后修改时间检查，而$httplib2$ 支持。

1.3ETags

  $ETag$ 是另一个和最后修改时间检查达到同样目的的方法。使用$ETag$时，服务器在返回数据的同时在$ETag$头里返回一个哈希码(如何生成哈希码完全取决于服务器，唯一的要求是数据改变时哈希码也要改变) diveintomark.org引用的背景图片包含有$ETag$ 头。

  当你再次请求同样的数据时，你在$If-None-Match$头里放入$ETag$值。如果数据没有发生改变，服务器将会返回304状态码。同最后修改时间检查一样，服务器发回的只有304 状态码，不会再一次给你发送同样的数据。通过在请求中包含$ETag$ 哈希码，你告诉服务器如果哈希值匹配就不需要重新发送同样的数据了，因为你仍然保留着上次收到的数据。

  ①$ETag$ 一般使用引号包围, 但是引号是值的一部分。它们不是分隔符；$ETag$头里面唯一的分隔符是$ETag$ 和 "3075-ddc8d800"之间的冒号。这意味着你也需要将引号放在$If-None-Match$头发回给服务器。

  $Pythonhttp$库不支持$ETag$，而$httplib2$支持。

1.4压缩

  当我们谈论$httpweb$ 服务的时候, 你总是会讨论到在线路上来回运送文本数据。可能是$xml$，也可能是$json$，抑或仅仅是纯文本。不管是什么格式，文本的压缩性能很好。$XML$ 章节中的示例供稿在没压缩的情况下是3070 字节，然而在$gzip$ 压缩后只有941 字节。仅仅是原始大小的30%！

  $http$支持若干种压缩算法。最常见的两种是$gzip$ 和 $deflate$。当你通过$http$请求资源时，你可以要求服务器以压缩格式返回资源。你在请求中包含一个$Accept-encoding$头，里面列出了你支持的压缩算法。如果服务器也支持其中的某一种算法，它就会返回给你压缩后的数据(同时通过$Content-encoding$头标识它使用的算法)。接下来的事情就是由你去解压数据了。

  $Python$的 $http$库不支持压缩，但$http$lib2支持。

1.5重定向

  好的$uri$不会变化，但是有很多$uri$并没有那么好。网站可能会重新组织，页面移动到新位置。即使是$web$ 服务也可能重新安排。一个联合供稿http://example.com/index.xml 可能会移动到http://example.com/xml/atom.xml。或者当一个机构扩张和重组的时候，整个域名都可能移动; http://www.example.com/index.xml 变成 http://server-farm-1.example.com/index.xml。

  每一次你向$http$服务器请求资源的时候, 服务器都会在响应中包含一个状态码。 状态码200的意思是一切正常，这就是你请求的页面; 状态码404的意思是找不到页面; (你很可能在浏览网页的时候碰到过404)。300 系列的状态码意味着某种形式的重定向。

  $http$ 有多种方法表示一个资源已经被移动。最常见两个技术是状态码302 和 301。 状态码 302 是一个临时重定向; 它意味着, 资源被被临时从这里移动走了; (并且临时地址在$Location$ 头里面给出)。状态码301是永久重定向; 它意味着，资源被永久的移动了; (并且在$Location$头里面给出了新的地址)。如果你得到302状态码和一个新地址, $http$规范要求你访问新地址来获得你要的资源，但是下次你要访问同样的资源的时候你应该重新尝试旧的地址。但是如果你得到301状态码和新地址, 你从今以后都应该使用新的地址。

  $urllib.request$模块在从$http$服务器收到对应的状态码的时候会自动“跟随”重定向, 但它不会告诉你它这么干了。你最后得到了你请求的数据，但是你永远也不会知道下层的库友好的帮助你跟随了重定向。结果是，你继续访问旧的地址，每一次你都会得到新地址的重定向，每一次$urllib.request$模块都会友好的帮你跟随重定向。换句话说，它将永久重定向当成临时重定向来处理。这意味着两个来回而不是一个，这对你和服务器都不好。

  $httplib2$ 帮你处理了永久重定向。它不仅会告诉你发生了永久重定向，而且它会在本地记录这些重定向，并且在发送请求前自动重写为重定向后的$url$。

2.避免通过 HTTP 重复地获取数据

  我们来举个例子，你想要通过$http$下载一个资源, 比如说一个Atom 供稿。作为一个供稿, 你不会只下载一次，你会一次又一次的下载它。 (大部分的供稿阅读器会每一小时检查一次更新。) 让我们先用最粗糙和最快的方法来实现它，接着再来看看怎样改进。

  ①在$Python$中通过$http$下载东西是非常简单的; 实际上，只需要一行代码。$urllib.request$模块有一个方便的函数$urlopen()$ ，它接受你所要获取的页面地址，然后返回一个类文件对象，您只要调用它的$read()$方法就可以获得网页的全部内容。没有比这更简单的了。
  ②$urlopen().read()$方法总是返回$bytes$对象,而不是字符串。记住字节仅仅是字节，字符只是一种抽象。 $http$ 服务器不关心抽象的东西。如果你请求一个资源，你得到字节。 如果你需要一个字符串，你需要确定字符编码,并显式的将其转化成字符串。

  那么，有什么问题呢？作为开发或测试中的快速试验，没有什么不妥的地方。我总是这么干。我需要供稿的内容，然后我拿到了它。相同的技术对任何网页都有效。但一旦你考虑到你需要定期访问$Web$服务的时候，(例如每隔1小时请求一下这个供稿), 这样的做法就显得很低效和粗暴了。

3.线路上是什么？

  为了说明为什么这是低效和粗暴的，我们来打开$Python$的$http$库的调试功能，看看什么东西被发送到了线路上(即网络上)。

  ①正如我在这章开头提到的，$urllib.request$ 依赖另一个标准Python库, $http.client$。正常情况下你不需要直接接触$http.client$。 ($urllib.request$ 模块会自动导入它。) 我们在这里导入它是为了让我们能够打开$HTTPConnection$类的调试开关，$urllib.request$ 使用这个类去连接$http$服务器。
  ②调试开关已经打开，有关$http$请求和响应的信息会实时的打印出来。正如你所看见的，当你请求$Atom$ 供稿时, $urllib.request$模块向服务器发送了5行数据。
  ③第一行指定了你使用的$http$方法和你访问的资源的路径(不包含域名)。
  ④第二行指定了你请求的供稿所在的域名。
  ⑤第三行指定客户端支持的压缩算法。我之前提到过，$urllib.request$ 默认不支持压缩。
  ⑥第四行说明了发送请求的库的名字。默认情况下是$Python-urllib$加上版本号。$urllib.request$和$httplib2$都支持更改用户代理, 直接向请求里面加一个$User-Agent$头就可以了(默认值会被覆盖)。
  本地用3.7版本测试，好像已经没有调试用的输出了。

  ①$urllib.request.urlopen()$函数返回的$response$对象包含了服务器返回的所有$http$头。它也提供了下载实际数据的方法，这个我们等一下讲。
  ②服务器提供了它处理你的请求时的时间。
  ③这个响应包含了$Last-Modified$头。
  ④这个响应包含了$ETag$头。
  ⑤数据的长度是3070字节。请注意什么东西没有出现在这里: $Content-encoding$头。你的请求表示你只接受未压缩的数据，(Accept-encoding: identity), 然后当然，响应确实包含未压缩的数据。
  ⑥ 这个响应包含缓存头，表明这个供稿可以缓存长达24小时。(86400 秒).
  ⑦ 最后，通过调用$response.read()$下载实际的数据. 你从$len()$函数可以看出，一下子就把整个3070个字节下载下来了。

  正如你所看见的，这个代码已经是低效的了；它请求(并接收)了未压缩的数据。

  注意到这个请求有什么特别之处吗？它没有变化。它同第一个请求完全一样。没有If-Modified-Since头。没有If-None-Match头。

  ①服务器仍然在发送同样的聪明的头: Cache-Control 和 Expires 用于允许缓存, Last-Modified 和 ETag用于“是否变化”的跟踪。甚至是Vary: Accept-Encoding头暗示只要你请求，服务器就能支持压缩。但是你没有。
  ②再一次，获取这个数据下载了一共3070个字节…
  ③…和你上一次下载的3070字节完全一致。

  $http$ 设计的能比这样工作的更好。 $urllib$使用$http$就像我说西班牙语一样 — 可以表达基本的意思，但是不足以保持一个对话。$http$ 是一个对话。是时候更新到一个可以流利的讲$http$的库了。

4.介绍 httplib2

  首先通过$pipinstallhttplib2$安装这个库。

  ①$httplib2$的主要接口是$Http$对象。你创建$Http$对象时总是应该传入一个目录名，具体原因你会在下一节看见。目录不需要事先存在，$httplib2$会在必要的时候创建它。
  ②一旦你有了$Http$对象, 获取数据非常简单，以你要的数据的地址作为参数调用$request()$方法就可以了。这会对该$url$执行一个$httpGET$请求. (这一章下面你会看见怎样执行其他$http$ 请求, 比如 $POST$。)
  ③$request()$ 方法返回两个值。第一个是一个$httplib2.Response$对象，其中包含了服务器返回的所有$http$头。比如, $status$为200 表示请求成功。
  ④$content$ 变量包含了$http$服务器返回的实际数据。数据以$bytes$对象返回，不是字符串。 如果你需要一个字符串，你需要确定字符编码并自己进行转换。

4.1关于httplib2返回字节串而不是字符串的简短解释

  字节串。字符串。真麻烦啊。为什么$httplib2$不能替你把转换做了呢？由于决定字符编码的规则依赖于你请求的资源的类型，导致自动转化很复杂。$httplib2$怎么知道你要请求的资源的类型呢？通常类型会在$Content-Typehttp$ 头里面列出,但是这是$http$的可选特性，并且并非所有的$http$服务器都支持。如果$http$响应没有包含这个头，那就留给客户端去猜了。

  如果你知道你期待的资源是什么类型的(这个例子中是$xml$文档), 也许你应该直接将返回的字节串($bytes$)对象传给$xml.etree.ElementTree.parse()$ 函数。只要(像这个文档一样)$xml$ 文档自己包含字符编码信息，这是可以工作的。但是字符编码信息是一个可选特性并非所有$xml$文档包含这样的信息。如果一个$xml$文档不包含编码信息，客户端应该去查看$Content-Typehttp$ 头, 里面应该包含一个$charset$参数。

4.2httplib2怎样处理缓存

  还记的在前一节我说过你总是应该在创建$httplib2.Http$对象时提供一个目录名吗? 缓存就是这样做的目的。

  ①让我们打开调试开关来看看线路上是什么。这是使用httplib2打开http.client调试开关的方法. httplib2会打印出发给服务器的所有数据以及一些返回的关键信息。
  ②使用同之前一样的目录创建httplib2.Http对象。
  ③请求同之前一样的url。 什么也没有发生。 更准确的说，没有东西发送到服务器，没有东西从服务器返回。没有任何形式的网络活动。
  ④但我们还是接收到了数据，实际上是所有的数据。
  ⑤我们也接收到表示请求成功的http状态码。
  ⑥这里是奥秘所在: 响应是从httplib2的本地缓存构造出来的。你创建httplib2.Http对象时传入的目录里面保存了所有httplib2执行过的操作的缓存。

  本地测试确实会有一个这样的文件：

  你刚刚请求过这个$url$的数据。那个请求是成功的(状态码: 200)。该响应不仅包含$feed$数据，也包含一系列缓存头，告诉那些关注着的人这个资源可以缓存长达24小时(Cache-Control: max-age=86400, 24小时所对应的秒数)。 $httplib2$ 理解并尊重那些缓存头，并且它会在$.cache$目录(你在创建$Http$对象时提供的)保存之前的响应。缓存还没有过期，所以你第二次请求该$url$的数据时,$ httplib2$不会去访问网络，直接返回缓存着的数据。

  我说的很简单，但是很显然在这简单后面隐藏了很多复杂的东西。$httplib2$会自动处理$http$缓存，并且这是默认的行为. 如果由于某些原因你需要知道响应是否来自缓存，你可以检查 $response.fromcache$。

  现在，假设你有数据缓存着，但是你希望跳过缓存并且重新请求远程服务器。浏览器有时候会应用户的要求这么做。比如说，按$F5$刷新当前页面，但是按$Ctrl+F5$会跳过缓存并向远程服务器重新请求当前页面。你可能会想“嗯，我只要从本地缓存删除数据，然后再次请求就可以了。” 你可以这么干，但是请记住, 不只是你和远程服务器会牵扯其中。那些中继代理服务器呢？ 它们完全不受你的控制，并且它们可能还有那份数据的缓存，然后很高兴的将其返回给你, 因为(对它们来说)缓存仍然是有效的。

  你应该使用$http$的特性来保证你的请求最终到达远程服务器，而不是修改本地缓存然后听天由命。

  ① $httplib2$ 允许你添加任意的$http$头部到发出的请求里。为了跳过所有缓存(不仅仅是你本地的磁盘缓存，也包括任何处于你和远程服务器之间的缓存代理服务器), 在$headers$字典里面加入$no-cache$头就可以了。
  ② 现在你可以看见$httplib2$初始化了一个网络请求。$httplib2$ 理解并尊重两个方向的缓存头， — 作为接受的响应的一部分以及作为发出的请求的一部分. 它注意到你加入了一个$no-cache$头，所以它完全跳过了本地的缓存，然后不得不去访问网络来请求数据。
  ③ 这个响应不是从本地缓存生成的。你当然知道这一点，因为你看见了发出的请求的调试信息。但是从程序上再验证一下也不错。
  ④ 请求成功；你再次从远程服务器下载了整个供稿。当然，服务器同供稿数据一起也返回了完整的$http$头。这里面也包含缓存头,$httplib2$会使用它来更新它的本地缓存，希望你下次请求该供稿时能够避免网络请求。$http$缓存被设计为尽量最大化缓存命中率和最小化网络访问。即使你这一次跳过了缓存，服务器仍非常乐意你能缓存结果以备下一次请求。

4.3httplib2怎么处理Last-Modified和ETag头

  $Cache-Control$和$Expires$ 缓存头被称为新鲜度指标(freshness indicators)。他们毫不含糊告诉缓存，你可以完全避免所有网络访问，直到缓存过期。而这正是你在前一节所看到的: 给出一个新鲜度指标, $httplib2$ 不会产生哪怕是一个字节的网络活动 就可以提供缓存了的数据(当然除非你显式的要求跳过缓存).

  那如果数据可能已经改变了, 但实际没有呢? $http$ 为这种目的定义了$Last-Modified$和$Etag$头。 这些头被称为验证器(validators)。如果本地缓存已经不是新鲜的，客户端可以在下一个请求的时候发送验证器来检查数据实际上有没有改变。如果数据没有改变，服务器返回304状态码，但不返回数据。 所以虽然还会在网络上有一个来回，但是你最终可以少下载一点字节。

  ① 取代供稿，我们这一次要下载的是网站的主页，是$html$格式的。这是你第一次请求这个页面，$httplib2$没什么能做的，它在请求中发出最少量的头。
  ② 响应包含了多个$http$头… 但是没有缓存信息。然而，它包含了$ETag$ 和 $Last-Modified$头。
  ③ 在我写这个例子的时候，这个页面有6657字节。在那之后，它很可能已经变了, 但是不用担心这一点。

  ① 你再次请求同一个页面，使用同一个$Http$对象(以及同一个本地缓存)。
  ② $httplib2$ 将$ETagvalidator$ 通过$If-None-Match$头发送回服务器。
  ③ $httplib2$ 也将$Last-Modifiedvalidator$ 通过$If-Modified-Since$头发送回服务器。
  ④ 服务器查看这些验证器($validators$), 查看你请求的页面，然后判读得出页面在上次请求之后没有改变过, 所以它发回了304 状态码不带数据.
  ⑤ 回到客户端，$httplib2$ 注意到304状态码并从它的缓存加载页面的内容。
  ⑥ 这可能会让人有些困惑。这里实际上有两个 状态码 — 304 (服务器这次返回的, 导致$httplib2$查看它的缓存), 和 200 (服务器上次返回的, 并和页面数据一起保存在$httplib2$的缓存里)。$response.status$返回缓存里的那个。
  ⑦ 如果你需要服务器返回的原始的状态码，你可以从$response.dict$里面找到, 它是包含服务器返回的真实头部的字典.
  ⑧ 然而，数据还是保存在了$content4变量里。一般来说，你不需要关心为什么响应是从缓存里面来的。(你甚至不需要知道它是从缓存里来的， 这是一件好事。 $httplib2$ 足够聪明，允许你傻瓜一点。) $request()$返回的时候, $httplib2$就已经更新了缓存并把数据返回给你了。

4.4http2lib怎么处理压缩

  ① 每一次$httplib2$ 发送请求，它包含了$Accept-Encoding$头来告诉服务器它能够处理$deflate$ 或者 $gzip$压缩。
  ② 这个例子中，服务器返回了$gzip$压缩过的负载，当$request()$方法返回的时候，$httplib2$就已经解压缩了响应的体(body)并将其放在 $content$变量里。如果你想知道响应是否压缩过, 你可以检查response[’-content-encoding’]。

4.5httplib2怎样处理重定向

  $http$ 定义了 两种类型的重定向: 临时的和永久的。对于临时重定向，除了跟随它们其他没有什么特别要做的, $httplib2$ 会自动处理跟随。

  ① 这个$url$上没有供稿。我设置了服务器让其发出一个到正确地址的临时重定向。
  ② 这是请求。
  ③ 这是响应: $302Found$。这里没有显示出来，这个响应也包含由一个$Location$头给出实际的$url$。
  ④ $httplib2$ 马上转身并跟随重定向，发出另一个到在$Location头$里面给出的url: http://diveintopython3.org/examples/feed.xml 的请求。

  “跟随” 一个重定向就是这个例子展示的那么多。$httplib2$ 发送一个请求到你要求的$url$。服务器返回一个响应说“不，不, 看那边。” $httplib2$ 给新的$url$发送另一个请求。

  你得到的$response$给了你最终 $url$的相关信息。如果你希望那些最后重定向到最终$url$的中间$url$的信息呢？$httplib2$ 也能帮你。

  ③ 再一次，服务器以302响应。但是请注意什么没有发生: 没有第二个到最终$url$, http://diveintopython3.org/examples/feed.xml 的请求。原因是缓存 (还记的你在前一个例子中看到的Cache-Control头吗？)。 一旦 $httplib2$ 收到$302Found$ 状态码, 它在发出新的请求前检查它的缓存。 缓存中有http://diveintopython3.org/examples/feed.xml的一份新鲜副本, 所以不需要重新请求它了。
  ④ 当 $request()$方法返回的时候，它已经从缓存中读取了$feed$数据并返回了它。当然，它和你上次收到的数据是一样的。

  换句话说，对于临时重定向你不需要做什么特别的处理。$httplib2$ 会自动跟随它们，而一个$url$重定向到另一个这个事实上不会影响$httplib2$对压缩，缓存, $ETags$, 或者任何其他$http$特性的支持。

5.HTTP GET之外

  $httpweb$ 服务并不限于$GET$请求。当你要创建点东西的时候呢？当你在论坛上发表一个评论，更新你的博客，在$Twitter$ 或者 $Identi.ca$这样的微博客上面发表状态消息的时候, 你很可能已经使用了$httpPOST$。

  怎么操作呢？要在$Identi.ca$ 发布一条消息, 你需要提交一个$httpPOST$请求到http://identi.ca/api/statuses/update.format. ($format$字样不是$url$的一部分; 你应该将其替换为你希望服务器返回的请求的格式。所以如果需要一个$xml$格式的返回。你应该向https://identi.ca/api/statuses/update.xml发送请求。) 请求需要一个参数$status$, 包含了你的状态更新文本。并且请求必须是已授权的。

  授权? 当然。要在$Identi.ca$上发布你的状态更新, 你得证明你的身份。$Identi.ca$ 不是一个维基; 只有你自己可以更新你的状态。$Identi.ca$ 使用建立在$ssl$之上的$httpBasicAuthentication$ (也就是RFC 2617) 来提供安全但方便的认证。$httplib2$ 支持$ssl$ 和 $httpBasicAuthentication$, 所以这部分很简单。

  $POST$ 请求同$GET$ 请求不同, 因为它包含负荷(payload)。负荷是你要发送到服务器的数据。这个$api$方法必须的参数是$status$, 并且它应该是$url$编码过的。 这是一种很简单的序列化格式，将一组键值对(比如字典)转化为一个字符串。

  ① 这是$httplib2$处理认证的方法。 $add\_credentials()$方法记录你的用户名和密码。当$httplib2$ 试图执行请求的时候，服务器会返回一个401 Unauthorized状态码, 并且列出所有它支持的认证方法(在 WWW-Authenticate 头中)。$httplib2$会自动构造Authorization头并且重新请求该$url$。
  ② 第二个参数是$http$请求的类型。这里是$POST$。
  ③ 第三个参数是要发送到服务器的负荷 。我们发送包含状态消息的$url$编码过的字典。
  ④ 最后，我们得告诉服务器负荷是$url$编码过的数据。

  $add\_credentials()$方法的第三个参数是该证书有效的域名。你应该总是指定这个参数! 如果你省略了这个参数，并且之后重用这个$httplib2.Http$对象访问另一个需要认证的站点，可能会导致$httplib2$将一个站点的用户名密码泄漏给其他站点。

6.HTTP POST之外