HttpClient jar4.5包是目前构建http协议的重要组成部分，当用户在使用HttpClient软件创建协议项目内容的时候，就需要用到HttpClient jar程序，让用户在创建的过程中更加稳定，程序的性能更加灵活，这款软件主要的目的就是帮助程序师在使用HttpClient软件的时候可以得到丰富的创建数据内容，在认证方案、字符编码、重定向处理、性能优化、偏好架构等方便得到最舒适的开发环境，从而提高开发的速度，加快http协议的稳定性，需要的朋友可以下载试试！
软件功能
服务器验证
HttpClient几乎透明地处理与服务器的身份验证，开发人员必须做的唯一事情实际上是提供登录凭据。这些凭据存储在HttpState实例中，可以使用setCredentials(AuthScope authscope, Credentials cred)和getCredentials(AuthScope authscope) 方法设置或检索。
可以使用setDoAuthentication(boolean doAuthentication) HttpMethod类中的方法禁用HttpClient中内置的自动授权。更改仅影响该方法实例。
抢占认证
可以在HttpClient中启用抢占认证。在这种模式下，HttpClient将在某些情况下甚至在服务器给出未授权响应之前发送基本认证响应，从而减少进行连接的开销。要启用此功能，请使用以下命令：
client.getParams（）。setAuthenticationPreemptive（true）;
抢占式身份验证模式还需要为要尝试抢占式身份验证的目标或代理主机设置默认凭据。未能提供默认凭据将导致抢占式身份验证模式无效。
凭据defaultcreds = new UsernamePasswordCredentials（“username”，“password”）;
client.getState（）。setCredentials（new AuthScope（“myhost”，80，AuthScope.ANY_REALM），defaultcreds）;
HttpClient中的抢占式身份验证符合rfc2617：
客户端应该假定在请求URI的路径字段中的最后符号元素的深度或深度以上的所有路径也在由当前询问的基本领域值指定的保护空间内。客户端可以预先发送相应的授权报头，其中请求该空间中的资源，而不从服务器接收另一询问。类似地，当客户端向代理发送请求时，其可以在代理授权报头字段中重用用户ID和密码，而不从代理服务器接收另一询问。
服务器认证的安全方面
在开发可能需要与不受信任的网站或Web应用程序通信的应用程序时，请谨慎使用默认凭据。当激活抢占认证或未明确给定特定认证域的凭证时，HttpClient将使用默认凭据尝试与目标站点进行身份验证。如果要避免将敏感凭据发送到不受信任的站点，请尽可能缩小凭证范围：始终指定主机和已知的凭据。
在生产应用程序中不建议使用AuthScope.ANY身份验证范围（null主机和/或域的值）设置凭据。这样做将导致为所有认证尝试（在抢占认证的情况下的所有请求）发送凭证。使用此设置应限于仅调试。
//要避免，除非在调试模式下
凭据defaultcreds = new UsernamePasswordCredentials（“username”，“password”）;
client.getState（）。setCredentials（AuthScope.ANY，defaultcreds）;
代理验证
HttpClient中的代理身份验证与服务器身份验证几乎相同，唯一的区别在于每个身份的凭据是独立存储的。因此，对于代理身份验证，您必须使用 setProxyCredentials(AuthScope authscope, Credentials cred)和 getProxyCredentials(AuthScope authscope)。
认证方案
HttpClient支持以下认证方案。
基本
基本认证是HTTP的原始和最兼容的认证方案。不幸的是，它也是最不安全的，因为它将未加密的用户名和密码发送到服务器。基本身份验证需要UsernamePasswordCredentials实例（NTCredentials扩展）可用于服务器指定的特定领域或默认凭据。
消化
Digest身份验证在HTTP 1.1协议中添加，虽然没有像Basic身份验证那么广泛支持，但是它提供了大量的支持。摘要认证比基本认证明显更安全，因为它从不在网络上传输实际密码，而是使用它来加密从服务器发送的“nonce”值。
摘要式身份验证需要UsernamePasswordCredentials实例（NTCredentials扩展）可用于服务器指定的特定领域或默认凭据。
软件特色
HTTP头
HTTP请求或响应的标头必须为US-ASCII格式。不能在请求或响应的标头中使用非US-ASCII字符。一般来说，这不是一个问题，因为HTTP头设计用于实现数据传输，而不是实际传输数据本身。
但是一个例外是cookie。因为cookie被转换为HTTP头，所以它们被限制在US-ASCII字符集。有关详细信息，请参阅Cookie指南。
请求/响应体
请求或响应正文可以是任何编码，但默认情况下是 ISO-8859-1。编码可以在 Content-Type头中指定，例如：
Content-Type：text / html; charset = UTF-8
在这种情况下，应用程序应仔细使用UTF-8编码，当将主体转换为字符串或一些字符可能已损坏。您可以使用addRequestHeader每个方法中的方法设置请求的内容类型标头，并使用该 方法检索响应正文的编码getResponseCharSet 。
如果已知响应是字符串，则可以使用getResponseBodyAsString将自动使用Content-Type头或 ISO-8859-1中指定的编码的 方法（如果未指定字符集）。
请注意，一些文档类型（如HTML和XML）允许作者指定文件的内容类型。在这种情况下，您应参阅相关标准，了解如何撤销所报告的字符集中的任何冲突。
使用方法
java.io.IOException
HttpClient中的通用传输异常由标准Java java.io.IOException类或其子类（如java.net.SocketException和java.net.InterruptedIOException）表示。
除了标准输入/输出异常类HttpClient定义几个自定义传输异常，传达HttpClient特定的信息。
在某些情况下，通常在负载较重时，Web服务器可能能够接收请求，但无法处理它们。缺乏足够的资源，如工作线程是一个很好的例子。这可能导致服务器删除到客户端的连接，而不给出任何响应。HttpClient在遇到这种情况时会抛出NoHttpResponseException。在大多数情况下，可以安全地重试使用NoHttpResponseException失败的方法。
此异常表示HttpClient无法在给定时间段内与目标服务器或代理服务器建立连接。
此异常仅在使用多线程连接管理器时发生。该异常表示连接管理器未能在给定时间段内从连接池获得空闲连接。
协议异常通常表示由客户端和服务器（web服务器或代理服务器）在解释HTTP规范时不匹配引起的逻辑错误。通常协议异常无法恢复，无需对客户端请求或服务器进行调整。HTTP规范的一些方面允许不同的，有时冲突的解释。HttpClient可以配置为支持不同程度的HTTP规范遵从性，从非常宽松到非常严格。
HttpException表示HttpClient中的抽象逻辑错误。通常这种异常不能从中自动恢复。
ProtocolException发出违反HTTP规范的信号。需要注意的是，HTTP代理和HTTP服务器可以具有不同级别的HTTP规范兼容性。通过将HttpClient配置为对非致命协议违例更宽松，可以从一些HTTP协议异常中恢复。
内部
MalformedChallengeException表示在给定的认证上下文中认证质询在某种程度上是无效的或非法的。
AuthenticationException表示认证过程中的失败。通常，当执行HTTP方法时，内部处理认证异常，并且不会传播到调用者。
当HttpClient无法响应服务器发送的任何身份验证挑战时，抛出AuthenticationException。
CredentialsNotAvailableException表示响应身份验证质询所需的凭据不可用。
相关介绍
HTTP传输安全
重要的是要理解HTTP协议不是很适合所有类型的应用程序。HTTP是一种简单的请求/响应导向协议，最初设计为支持静态或动态生成的内容检索。它从来没有打算支持事务操作。例如，如果HTTP服务器成功地接收和处理请求，生成响应并将状态代码发送回客户端，则HTTP服务器将考虑其履行的合同部分。如果客户端由于读取超时，请求取消或系统崩溃而无法完全接收响应，则服务器不会尝试回滚事务。如果客户端决定重试相同的请求，则服务器将不可避免地结束多次执行相同的事务。在某些情况下，这可能导致应用程序数据损坏或应用程序状态不一致。
尽管HTTP从未被设计为支持事务处理，但是如果满足某些条件，它仍然可以用作关键任务应用的传输协议。为了确保HTTP传输层安全，系统必须确保HTTP方法在应用层上的幂等性。
幂等方法
HTTP / 1.1规范将幂等方法定义为
方法也可以具有“幂等性”的属性（除了错误或到期问题），N> 0相同请求的副作用与单个请求的副作用相同。
换句话说，应用程序应该确保它准备处理多个执行相同方法的影响。这可以例如通过提供唯一的事务id以及通过避免执行相同的逻辑操作的其他手段来实现。
请注意，此问题不是特定于HttpClient。基于浏览器的应用程序受到与HTTP方法非幂等性完全相同的问题。
自动异常恢复
默认情况下，HttpClient尝试自动从异常恢复。默认的自动恢复机制仅限于已知安全的少数异常。
HttpClient将不会尝试从任何逻辑或HTTP协议错误（从HttpException类派生）。
当HTTP请求仍在传输到目标服务器（即请求尚未完全传输到服务器）时，HttpClient将自动重试最多5次失败传输异常的方法。
HttpClient将自动重试最多5次那些已经完全传输到服务器的方法，但服务器无法响应HTTP状态代码（服务器简单地删除连接，不发送任何回）。在这种情况下，假定请求未被服务器处理，并且应用程序状态未更改。如果这个假设可能不适用于您的应用程序定向的Web服务器，强烈建议提供自定义异常处理程序。
∨ 展开