ASIHttpRequest-发送数据

发送数据

设定request头

使用ASIFormDataRequest POST表单

通常数据是以’application/x-www-form-urlencoded’格式发送的，如果上传了二进制数据或者文件，那么格式将自动变为‘multipart/form-data’ 

文件中的数据是需要时才从磁盘加载，所以只要web server能处理，那么上传大文件是没有问题的。

数据的mime头是自动判定的，但是如果你想自定义mime头，那么这样：

你可以使用addPostValue方法来发送相同name的多个数据（梦维：服务端会以数组方式呈现）：

PUT请求、自定义POST请求

如果你想发送PUT请求，或者你想自定义POST请求，使用appendPostData: 或者 appendPostDataFromFile:

ASIHTTPRequest-下载数据

将服务器响应数据直接下载到文件

如果你请求的资源很大，你可以直接将数据下载到文件中来节省内存。此时，ASIHTTPRequest将不会一次将返回数据全部保持在内存中。

当我们把数据下载到downloadDestinationPath时，数据将首先被存在临时文件中。此时文件的路径名存储在temporaryFileDownloadPath中(梦维：如果不设置这个值，会自动生成一个文件名，在模拟器中，文件被创建在$TMPDIR中)。当request完成时，会发生下面两件事之一：

• 如果数据是被压缩过（gzip）的，那么这个压缩过的文件将被解压到downloadDestinationPath，临时文件会被删除。
• 如果数据未被压缩，那么这个文件将被移动到downloadDestinationPath，冲突解决方式是：覆盖已存在的文件。

注意，如果服务器响应数据为空，那么文件是不会被创建的。如果你的返回数据可能为空，那么你应该先检查下载文件是否存在，再对文件进行操作。

处理收到的服务器响应数据

如果你想处理服务器响应的数据（例如，你想使用流解析器对正在下载的数据流进行处理），你应该实现代理函数 request:didReceiveData:。注意如果你这么做了，ASIHTTPRequest将不会填充responseData到内存，也不会将数据写入文件（downloadDestinationPath ）——你必须自己搞定这两件事（之一）。 

获取HTTP状态码

ASIHTTPRequest并不对HTTP状态码做任何处理（除了重定向和授权状态码，下面会介绍到），所以你必须自己检查状态值并正确处理。

读取响应头

处理文本编码

ASIHTTPRequest会试图读取返回数据的编码信息（Content-Type头信息）。如果它发现了编码信息，它会将编码信息设定为合适的 NSStringEncoding.如果它没有找到编码信息，它会将编码设定为默认编码（NSISOLatin1StringEncoding）。

当你调用[request responseString]，ASIHTTPRequest会尝试以responseEncoding将返回的Data转换为NSString。

处理重定向

当遇到以下HTTP状态码之一时，ASIHTTPRequest会自动重定向到新的URL：

• 301 Moved Permanently
• 302 Found
• 303 See Other

当发生重定向时，响应数据的值（responseHeaders，responseCookies，responseData，responseString等等）将会映射为最终地址的相应返回数据。

当URL发生循环重定向时，设置在这个URL上的cookie将被储存到全局域中，并在适当的时候随重定向的请求发送到服务器。

Cookies set on any of the urls encountered during a redirection cycle will be stored in the global cookie store, and will be represented to the server on the redirected request when appropriate.

你可以关闭自动重定向：将shouldRedirect设置为NO。

默认情况下，自动重定向会使用GET请求（请求体为空）。这种行为符合大多数浏览器的行为，但是HTTP spec规定301和302重定向必须使用原有方法。

要对301、302重定向使用原方法（包含请求体），在发起请求之前，设置shouldUseRFC2616RedirectBehaviour 为YES。

ASIHTTPRequest-进度追踪

每个ASIHTTPRequest有两个delegate用来追踪进度：

• downloadProgressDelegate 下载)
• uploadProgressDelegate (上载).

进度delegate可以是NSProgressIndicators (Mac OS X) 或者 UIProgressViews (iPhone).ASIHTTPRequest会自适应这两个class的行为。你也可以使用自定义class作为进度delegate，只要它响应setProgress:函数。

• 如果你执行单个request，那么你需要为该request设定upload/download进度delegate
• 如果你在进行多个请求，并且你想要追踪整个队列中的进度，你必须使用ASINetworkQueue并设置队列的进度delegate
• 如果上述两者你想同时拥有，恭喜你，0.97版以后的ASIHTTPRequest，这个可以有 ^ ^

IMPORTANT:如果你向一个要求身份验证的网站上传数据，那么每次授权失败，上传进度条就会被重置为上一次的进度值。因此，当与需要授权的web服务器交互时，建议仅当useSessionPersistence为YES时才使用上传进度条，并且确保你在追踪大量数据的上传进度之前，先使用另外的request来进行授权。 

追踪小于128KB的数据上传进度目前无法做到，而对于大于128kb的数据，进度delegate不会收到第一个128kb数据块的进度信息。这是因为CFNetwork库API的限制。我们曾向apple提交过bug报告（bug id 6596016），希望apple能修改CFNetwork库以便实现上述功能。

2009-6-21：Apple的哥们儿们真棒！iPhone 3.0 SDK里，buffer大小已经被减小到32KB了，我们的上传进度条可以更精确了。

追踪单个request的下载进度

这个例子中， myProgressIndicator是个 NSProgressIndicator.

追踪一系列request的下载进度

在这个例子中, myProgressIndicator 是个 UIProgressView, myQueue是个 ASINetworkQueue.

这个例子中，我们已经为ASINetworkQueues调用过[myQueue go]了。

追踪单个request的上传进度

在这个例子中, myProgressIndicator 是个 UIProgressView。

追踪一系列request的上传进度

这个例子中, myProgressIndicator是个 NSProgressIndicator, myQueue是个ASINetworkQueue.

精确进度条vs简单进度条

ASIHTTPRequest提供两种进度条显示，简单进度条和精确进度条，使用ASIHTTPRequests 和ASINetworkQueues的showAccurateProgress 来控制。为一个request设置showAccurateProgress只会对该request有效。如果你为一个队列设置showAccurateProgress，那么会影响队列里所有的request。

简单进度条

当使用简单进度条时，进度条只会在一个request完成时才更新。对于单个request，这意味着你只有两个进度状态：0%和100%。对于一个有5个request的队列来说，有五个状态：0%，25%，50%，75%，100%，每个request完成时，进度条增长一次。

简单进度条（showAccurateProgress = NO）是ASINetworkQueue的默认值，适用于大量小数据请求。

精确进度条

当使用精确进度条时，每当字节被上传或下载时，进度条都会更新。它适用于上传/下载大块数据的请求，并且会更好的显示已经发送/接收的数据量。

使用精确进度条追踪上传会轻微降低界面效率，因为进度delegate（一般是UIProgressViews 或NSProgressIndicators）会更频繁地重绘。

使用精确进度条追踪下载会更影响界面效率，因为队列会先为每个GET型request进行HEAD请求，以便统计总下载量。强烈推荐对下载大文件的队列使用精确进度条，但是要避免对大量小数据请求使用精确进度条。

精确进度条（showAccurateProgress = YES）是以同步方式执行的ASIHTTPRequest的默认值。

自定义进度追踪

ASIProgressDelegate 协议定义了所有能更新一个request进度的方法。多数情况下，设置你的uploadProgressDelegate或者 downloadProgressDelegate为 NSProgressIndicator或者UIProgressView会很好。但是，如果你想进行更复杂的追踪，你的进度delegate实现下列函数要比 setProgress: (iOS) 或者 setDoubleValue: / setMaxValue: (Mac)好：

这些函数允许你在实际量的数据被上传或下载时更新进度，而非简单方法的0到1之间的数字。

downloadProgressDelegates方法

• request:didReceiveBytes: 每次request下载了更多数据时，这个函数会被调用（注意，这个函数与一般的代理实现的 request:didReceiveData:函数不同）。
• request:incrementDownloadSizeBy: 当下载的大小发生改变时，这个函数会被调用，传入的参数是你需要增加的大小。这通常发生在request收到响应头并且找到下载大小时。

uploadProgressDelegates方法

• request:didSendBytes: 每次request可以发送更多数据时，这个函数会被调用。注意：当一个request需要消除上传进度时（通常是该request发送了一段数据，但是因为授权失败或者其他什么原因导致这段数据需要重发）这个函数会被传入一个小于零的数字。

ASIHTTPRequest-HTTP授权-流程图

ASIHTTPRequest-Cookie的使用

持久化cookie

ASIHTTPRequest允许你使用全局存储来和所有使用CFNetwork或者NSURLRequest接口的程序共享cookie。

如果设置useCookiePersistence为YES（默认值），cookie会被存储在共享的 NSHTTPCookieStorage 容器中，并且会自动被其他request重用。值得一提的是，ASIHTTPRequest会向服务器发送其他程序创建的cookie（如果这些cookie对特定request有效的话）。

你可以清空session期间创建的所有cookie：

这里的‘session cookies’指的是一个session中创建的所有cookie，而非没有过期时间的cookie（即通常所指的会话cookie，这种cookie会在程序结束时被清除）。

另外，有个方便的函数 clearSession可以清除session期间产生的所有的cookie和缓存的授权数据。 

自己处理cookie

如果你愿意，你大可以关闭useCookiePersistence，自己来管理某个request的一系列cookie：

ASIHTTPRequest-数据压缩

使用gzip来处理压缩的响应数据

从0.9版本开始，ASIHTTPRequest会提示服务器它可以接收gzip压缩过的数据。

许多web服务器可以在数据被发送之前压缩这些数据——这可以加快下载速度减少流量使用，但会让服务器的cpu（压缩数据）和客户端（解压数据）付出代价。总的来说，只有特定的几种数据会被压缩——许多二进制格式的文件像jpeg，gif，png，swf和pdf已经压缩过他们的数据了，所以向客户端发送这些数据时不会进行gzip压缩。文本文件例如网页和xml文件会被压缩，因为它们通常有大量的数据冗余。

怎样设置apache的mod_deflate来使用gzip压缩数据

apache 2.x以上版本已经配备了mod_deflate扩展，这使得apache可以透明地压缩特定种类的数据。要开启这个特性，你需要在apache的配置文件中启用mod_deflate。并将mod_deflate命令添加到你的虚拟主机配置或者.htaccess文件中。

在ASIHTTPRequest中使用gzip

当allowCompressedResponse 设置为YES时，ASIHTTPRequest将向request中增加一个Accept-Encoding头，表示我们可以接收gzip压缩过的数据。如果响应头中包含一个Content-Encoding头指明数据是压缩过的，那么调用responseData 或者responseString 将会得到解压缩后的数据。你也可以通过调用rawResponseData来获得原始未压缩的数据。

相应数据的实时解压缩

默认情况下，ASIHTTPRequest会等到request完成时才解压缩返回的数据。若设置request的shouldWaitToInflateCompressedResponses 属性为NO，ASIHTTPRequest将会对收到的数据进行实时解压缩。 在某些情况下，这会稍稍提升速度，因为数据可以在reqeust等待网络数据时进行处理。

如果你需要对响应数据流进行流处理（例如XML和JSON解析），这个特性会很有用。如果启用了这个选项，你可以通过实现代理函数request:didReceiveData:来将返回的网络数据一点一点喂给解析器。

注意，如果shouldWaitToInflateCompressedResponses 被设置为NO，那么原始（未解压）的数据会被抛弃。具体情况请查阅ASIHTTPRequest.h的代码注释。

使用gzip压缩request数据

1.0.3版本的新特性就是gzip压缩request数据。使用这个特性，你可以通过设置shouldCompressRequestBody 为YES来使你的程序压缩POST/PUT的内容，默认值为NO。

apache的mod_deflate可以自动解压缩gzip压缩的请求体（通过合适的设置）。这个方法适用于CGI内容，但不适用于内容过滤器式的模块（例如mod PHP），这种情况下，你就必须自己解压缩数据。

ASIHTTPRequest 无法检测一个服务器是否能接收压缩过的请求体。当你确定服务器可以解压缩gzip包时，再使用这个特性。

请避免对已经压缩过的格式（例如jpeg/png/gif/pdf/swf）进行压缩，你会发现压缩后的数据比原数据更大。（梦维：因为压缩包都有头信息）

ASIHTTPRequest-断点续传（下载）

从0.94版本开始，ASIHTTPRequest可以恢复中断的下载

这个特性只对下载数据到文件中有效，你必须为一下情况的request设置allowResumeForFileDownloads 为YES：

• 任何你希望将来可以断点续传的下载（否则，ASIHTTPRequest会在取消或者释放内存时将临时文件删除）
• 任何你要进行断点续传的下载

另外，你必须自己设置一个临时下载路径（setTemporaryFileDownloadPath），这个路径是未完成的数据的路径。新的数据将会被添加到这个文件，当下载完成时，这个文件将被移动到downloadDestinationPath 。

断点续传的工作原理是读取temporaryFileDownloadPath的文件的大小，并使用Range: bytes=x HTTP头来请求剩余的文件内容。

ASIHTTPRequest并不检测是否存在Accept-Ranges头（因为额外的HEAD头请求会消耗额外的资源），所以只有确定服务器支持断点续传下载时，再使用这个特性。

ASIHTTPRequest-直接读取磁盘数据流的请求体

从0.96版本开始，ASIHTTPRequest可以使用磁盘上的数据来作为请求体。这意味着不需要将文件完全读入内存中，这就避免的当使用大文件时的严重内存消耗。

使用这个特性的方法有好几种：

ASIFormDataRequests

当使用setFile:forKey:时，ASIFormDataRequests 自动使用这个特性。request将会创建一个包含整个post体的临时文件。文件会一点一点写入post体。这样的request是由CFReadStreamCreateForStreamedHTTPRequest创建的，它使用文件读取流来作为资源。

普通ASIHTTPRequest

如果你明白自己的request体会很大，那么为这个request设置流式读取模式。

下面的例子中，我们将一个NSData对象添加到post体。这有两个方法：从内存中添加（appendPostData:），或者从文件中添加（appendPostDataFromFile:）；

这个例子中，我们想直接PUT一个大文件。我们得自己设置setPostBodyFilePath ，ASIHTTPRequest将使用这个文件来作为post体。

IMPORTANT:切勿对使用上述函数的request使用setPostBody——他们是互斥的。只有在你要自己建立request的请求体，并且还准备在内存中保持这个请求体时，才应该使用setPostBody。

ASIHTTPRequest-使用download cache

从1.8版本开始，ASIDownloadCache和ASICacheDelegate的API改变了，你可能需要修改你的代码。

尤其是，cache策略的可用选项发生了改变，你现在可以对单一request使用结合的cache策略

ASIHTTPRequest可以自动缓存下载的数据。在很多情况下这很有用：

• 当你离线时，你无法再次下载数据，而你又需要访问这些数据
• 从上次下载这些数据后，你只想在数据更新后才下载新的数据
• 你处理的数据永远不会发生改变，所以你只想下载一次数据

在之前版本的ASIHTTPRequest里，遇到上述情况，你只能自己处理这些策略。在一些情况下，使用download cache可以让你不用再写本地缓存机制。

ASIDownloadCache 是个简单的URL cache，可以用来缓存GET请求的相应数据。一个request要被缓存，它首先必须请求成功（没有发送错误），服务器必须返回200HTTP状态值。或者，从1.8.1版本开始，301,302,303,307重定向状态码都可以。

要打开响应值的cache机制很简单：

这样做以后，所有的request都会自动使用cache。如果你愿意，你可以让不同的request使用共享的cache：

你不会被局限于使用单一的cache，你可以想创建多少cache就创建多少cache，只要你喜欢 ^ ^。当你自己创建一个cache，你必须设定cache的路径——这路径必须是一个你拥有写权限的目录。

cache策略

cache策略是你控制cache中信息的主要方法，控制何时使用cache数据而非重新下载数据。

每个request的cache策略可是由request的cachePolicy 属性来控制的。cache策略使用掩码来定义，所以你可以二进制“与”操作他们。

你可以使用下列cache策略选项来控制request的缓存策略：

当你设定了一个cache对象的defaultCachePolicy 属性，所有使用这个cache对象的request都会使用这个cache策略，除非你为request设置了另外的策略。

存储策略

存储策略允许你定义一个cache可以存储特定的相应数据多久。ASIHTTPRequest目前支持两种存储策略：

ASICacheForSessionDurationCacheStoragePolicy是默认值。相应数据只会在会话期间被存储，在第一次使用cache时，或者在调用 [ASIHTTPRequest clearSession]时，数据会被清除。

使用ASICachePermanentlyCacheStoragePolicy，缓存的相应数据会被永久存储。要使用这个存储策略，向request设置：

要手动清除cache，调用函数clearCachedResponsesForStoragePolicy:,传入要清除的cache数据的存储策略：

其他cache相关的特性

编写自己的cache

如果你已经持有一个download cache并且想将他插入ASIHTTPRequest中，或者你喜欢自己写自己的download cache，那么让你的cache实现ASICacheDelegate协议。