HttpClient jar4.5包

HttpClient jar4.5包是目前构造http协议的重要组成部分。当用户使用HttpClient软件创建协议项目内容时，需要使用HttpClient jar程序，使用户在创建过程中更加稳定，程序的性能更加灵活。该软件的主要目的是帮助程序员在使用HttpClient软件时获得丰富的创建数据内容，在认证方案、字符编码、重定向处理、性能优化、首选架构等方面获得最舒适的开发环境，从而提高开发速度，加快http协议的稳定性。有需要的朋友可以下载试试！

软件功能

服务器认证

HttpClient几乎透明地处理与服务器的身份验证，开发人员唯一要做的就是实际提供登录凭证。这些凭据存储在HttpState实例中，可以使用set credentials(auth scope auth scope，credentials cred)和get credentials(auth scope auth scope)方法进行设置或检索。

您可以使用setdoauthentication(boolean doauthentication)http method类中的方法来禁用HttpClient中的内置自动授权。更改仅影响此方法实例。

抢先认证

可以在HttpClient中启用抢先身份验证。在这种模式下，HttpClient在某些情况下甚至会在服务器给出未授权的响应之前发送一个基本的身份验证响应，从而减少连接的开销。要启用此功能，请使用以下命令：

client.getParams().setAuthenticationPreemptive(true)；

抢先身份验证模式还要求为将尝试抢先身份验证的目标或代理主机设置默认凭据。未能提供默认凭据将导致抢先身份验证模式无效。

credentials default credits=new username password credentials("用户名"，"密码")；

client.getState().setCredentials(新的AuthScope("myhost "，80，AuthScope。ANY_REALM)、default creds)；

HttpClient中的抢先身份验证符合rfc2617:

客户端应该假设在请求URI的路径字段中的最后一个符号元素的深度之上的所有路径也在由当前查询的基本域值指定的保护空间内。客户端可以预先发送相应的授权头，其中请求空间中的资源，而无需从服务器接收另一个查询。类似地，当客户端向代理发送请求时，它可以在代理授权头字段中重用用户ID和密码，而无需从代理服务器接收另一个查询。

服务器身份验证的安全方面

在开发可能需要与不受信任的网站或web应用程序通信的应用程序时，请小心使用默认凭据。当激活抢先身份验证或未明确给出特定身份验证域的凭据时，HttpClient将尝试使用默认凭据向目标站点进行身份验证。如果您希望避免向不受信任的站点发送敏感凭据，请尽可能缩小凭据的范围：始终指定主机和已知凭据。

使用AuthScope。不建议在生产应用程序中使用任何身份验证范围(空主机和/或域的值)来设置凭据。这样做将导致为所有身份验证尝试发送凭据(抢先身份验证情况下的所有请求)。此设置的使用应仅限于调试。

//避免它，除了在调试模式下。

credentials default credits=new username password credentials("用户名"，"密码")；

client.getState().setCredentials(AuthScope。任何，default creds)；

代理验证

HttpClient中的代理身份验证与服务器身份验证几乎相同，唯一的区别是每个身份的凭证是独立存储的。因此，对于代理身份验证，必须使用setproxy凭据(authscope authscope，credentials cred)和getproxy凭据(authscope authscope)。

认证方案

HttpClient支持下列身份验证方案。

基础

基本身份验证是HTTP的原始且最兼容的身份验证方案。不幸的是，它也是最不安全的，因为它向服务器发送未加密的用户名和密码。基本身份验证要求UsernamePasswordCredentials(nt credentials扩展)的实例可用于服务器指定的特定领域或默认凭据。

摘要

HTTP 1.1协议中添加了摘要式身份验证。虽然它不像基本身份验证那样受到广泛支持，但它提供了很多支持。身份验证显然比基本身份验证更安全，因为它从不在网络上传输实际的密码，而是使用它来加密从服务器发送的“nonce”值。

摘要式身份验证要求UsernamePasswordCredentials(nt credentials扩展)的实例可用于服务器指定的特定领域或默认凭据。

软件特色

HTTP标头

HTTP请求或响应的标头必须采用US-ASCII格式。不能在请求或响应的标头中使用非US-ASCII字符。一般来说，这不是问题，因为HTTP头是为数据传输而设计的，而不是实际传输数据本身。

但饼干是个例外。因为cookie被转换成HTTP头，所以它们被限制为US-ASCII字符集。有关更多信息，请参见Cookie指南。

请求/响应主体

请求或响应的主体可以是任何编码，但默认情况下是ISO-8859-1。可以在内容类型头中指定编码，例如：

内容类型：文本/html；字符集=UTF-8

在这种情况下，应用程序应该小心使用UTF-8编码，在将正文转换为字符串时，一些字符可能会被损坏。您可以使用addRequestHeader的每个方法中的方法来设置请求的内容类型标头，并使用此方法来检索响应正文的编码getResponseCharSet。

如果已知响应是一个字符串，可以使用getResponseBodyAsString自动使用Content-Type头或ISO-8859-1(如果没有指定字符集)中指定的编码方法。

请注意，一些文档类型，如HTML和XML，允许作者指定文件的内容类型。在这种情况下，您应该参考相关标准，以了解如何在报告的字符集中撤销任何冲突。

使用方法

Java . io . io异常

HttpClient中的一般传输异常由标准的java.io.ioexception类或其子类(如java.net.SocketException和Java . net . interruptedioexception)表示。

除了标准的输入/输出异常类HttpClient之外，还定义了几个自定义传输异常来传达HttpClient的特定信息。

在某些情况下，通常当负载很重时，Web服务器可以接收请求，但不能处理它们。缺少足够的资源，比如工作线程，就是一个很好的例子。这可能会导致服务器删除与客户端的连接，而不给出任何响应。HttpClient遇到这种情况会抛出NoHttpResponseException。在大多数情况下，使用NoHttpResponseException重试失败的方法是安全的。

此异常表明HttpClient无法在给定的时间段内与目标服务器或代理服务器建立连接。

只有在使用多线程连接管理器时，才会出现此异常。此异常表明连接管理器无法在给定的时间内从连接池中获取空闲连接。

协议异常通常表示在解释HTTP规范时，由于客户端和服务器(web服务器或代理服务器)之间的不匹配而导致的逻辑错误。通常情况下，协议异常无法恢复，不需要调整客户端请求或服务器。HTTP规范的某些方面允许不同的、有时是冲突的解释。HttpClient可以配置为支持不同程度的HTTP规范遵从性，从非常宽松到非常严格。

HttpException表示HttpClient中的抽象逻辑错误。通常，这种异常不能自动从中恢复。

ProtocolException表示违反了HTTP规范。应该注意，HTTP代理和HTTP服务器可以具有不同级别的HTTP规范兼容性。通过将HttpClient配置为对非致命的协议违规更加宽容，可以从一些HTTP协议异常中恢复。

里面的

MalformedChallengeException意味着在给定的身份验证上下文中，身份验证质询在某种程度上是无效或非法的。

AuthenticationException表示身份验证过程失败。通常，当执行HTTP方法时，身份验证异常在内部处理，不会传播到调用方。

当HttpClient无法响应服务器发送的任何身份验证质询时，将引发AuthenticationException。

credentials NOTAvailableException表示响应身份验证质询所需的凭据不可用。

相关介绍

HTTP传输安全性

了解HTTP协议并不适用于所有类型的应用程序是很重要的。HTTP是一个简单的面向请求/响应的协议，最初设计用于支持静态或动态生成的内容检索。它从来没有打算支持事务性操作。例如，如果HTTP服务器成功地接收并处理请求，生成响应并将状态代码发送回客户端，则HTTP服务器将考虑它履行的那部分合同。如果客户端由于读取超时、请求取消或系统崩溃而无法完全接收到响应，服务器将不会尝试回滚事务。如果客户机决定重试同一请求，服务器将不可避免地多次结束执行同一事务。在某些情况下，这可能会导致应用程序数据损坏或应用程序状态不一致。

尽管HTTP从未被设计为支持事务处理，但如果满足某些条件，它仍然可以用作任务关键型应用程序的传输协议。为了保证HTTP传输层的安全性，系统必须保证HTTP方法在应用层的幂等性。

幂等方法

HTTP/1.1规范将幂等方法定义为

方法也可以有“幂等”的性质(错误或者过期问题除外)，同一个请求的副作用和单个请求的副作用是一样的。

换句话说，应用程序应该确保准备好处理同一方法多次执行的影响。例如，这可以通过提供唯一的事务id以及通过避免执行相同逻辑操作的其他手段来实现。

请注意，这个问题不是HttpClient特有的。基于浏览器的应用程序遭受与HTTP方法完全相同的问题。

自动异常恢复

默认情况下，HttpClient尝试自动从异常中恢复。默认的自动恢复机制仅限于少数已知安全的例外情况。

HttpClient不会试图犯任何逻辑或HTTP协议错误(从HttpException类派生)。

当HTTP请求仍在传输到目标服务器时(即请求尚未完全传输到服务器)，HttpClient将自动重试传输异常失败的方法，最多5次。

HttpClient会自动重试已经完整传输到服务器的方法，最多5次，但是服务器无法响应HTTP状态码(服务器只是删除连接，不发送任何回复)。在这种情况下，假设服务器没有处理请求，并且应用程序状态没有改变。如果这个假设不适用于面向应用程序的Web服务器，那么强烈建议提供一个定制的异常处理程序。