You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

HttpConnection.java 11KB

Add support to follow HTTP redirects git-core follows HTTP redirects so JGit should also provide this. Implement config setting http.followRedirects with possible values "false" (= never), "true" (= always), and "initial" (only on GET, but not on POST).[1] We must do our own redirect handling and cannot rely on the support that the underlying real connection may offer. At least the JDK's HttpURLConnection has two features that get in the way: * it does not allow cross-protocol redirects and thus fails on http->https redirects (for instance, on Github). * it translates a redirect after a POST to a GET unless the system property "http.strictPostRedirect" is set to true. We don't want to manipulate that system setting nor require it. Additionally, git has its own rules about what redirects it accepts;[2] for instance, it does not allow a redirect that adds query arguments. We handle response codes 301, 302, 303, and 307 as per RFC 2616.[3] On POST we do not handle 303, and we follow redirects only if http.followRedirects == true. Redirects are followed only a certain number of times. There are two ways to control that limit: * by default, the limit is given by the http.maxRedirects system property that is also used by the JDK. If the system property is not set, the default is 5. (This is much lower than the JDK default of 20, but I don't see the value of following so many redirects.) * this can be overwritten by a http.maxRedirects git config setting. The JGit http.* git config settings are currently all global; JGit has no support yet for URI-specific settings "http.<pattern>.name". Adding support for that is well beyond the scope of this change. Like git-core, we log every redirect attempt (LOG.info) so that users may know about the redirection having occurred. Extends the test framework to configure an AppServer with HTTPS support so that we can test cloning via HTTPS and redirections involving HTTPS. [1] https://git-scm.com/docs/git-config [2] https://kernel.googlesource.com/pub/scm/git/git/+/6628eb41db5189c0cdfdced6d8697e7c813c5f0f [3] https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html CQ: 13987 Bug: 465167 Change-Id: I86518cb76842f7d326b51f8715e3bbf8ada89859 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
9 years ago
Add support to follow HTTP redirects git-core follows HTTP redirects so JGit should also provide this. Implement config setting http.followRedirects with possible values "false" (= never), "true" (= always), and "initial" (only on GET, but not on POST).[1] We must do our own redirect handling and cannot rely on the support that the underlying real connection may offer. At least the JDK's HttpURLConnection has two features that get in the way: * it does not allow cross-protocol redirects and thus fails on http->https redirects (for instance, on Github). * it translates a redirect after a POST to a GET unless the system property "http.strictPostRedirect" is set to true. We don't want to manipulate that system setting nor require it. Additionally, git has its own rules about what redirects it accepts;[2] for instance, it does not allow a redirect that adds query arguments. We handle response codes 301, 302, 303, and 307 as per RFC 2616.[3] On POST we do not handle 303, and we follow redirects only if http.followRedirects == true. Redirects are followed only a certain number of times. There are two ways to control that limit: * by default, the limit is given by the http.maxRedirects system property that is also used by the JDK. If the system property is not set, the default is 5. (This is much lower than the JDK default of 20, but I don't see the value of following so many redirects.) * this can be overwritten by a http.maxRedirects git config setting. The JGit http.* git config settings are currently all global; JGit has no support yet for URI-specific settings "http.<pattern>.name". Adding support for that is well beyond the scope of this change. Like git-core, we log every redirect attempt (LOG.info) so that users may know about the redirection having occurred. Extends the test framework to configure an AppServer with HTTPS support so that we can test cloning via HTTPS and redirections involving HTTPS. [1] https://git-scm.com/docs/git-config [2] https://kernel.googlesource.com/pub/scm/git/git/+/6628eb41db5189c0cdfdced6d8697e7c813c5f0f [3] https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html CQ: 13987 Bug: 465167 Change-Id: I86518cb76842f7d326b51f8715e3bbf8ada89859 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
9 years ago
Add support to follow HTTP redirects git-core follows HTTP redirects so JGit should also provide this. Implement config setting http.followRedirects with possible values "false" (= never), "true" (= always), and "initial" (only on GET, but not on POST).[1] We must do our own redirect handling and cannot rely on the support that the underlying real connection may offer. At least the JDK's HttpURLConnection has two features that get in the way: * it does not allow cross-protocol redirects and thus fails on http->https redirects (for instance, on Github). * it translates a redirect after a POST to a GET unless the system property "http.strictPostRedirect" is set to true. We don't want to manipulate that system setting nor require it. Additionally, git has its own rules about what redirects it accepts;[2] for instance, it does not allow a redirect that adds query arguments. We handle response codes 301, 302, 303, and 307 as per RFC 2616.[3] On POST we do not handle 303, and we follow redirects only if http.followRedirects == true. Redirects are followed only a certain number of times. There are two ways to control that limit: * by default, the limit is given by the http.maxRedirects system property that is also used by the JDK. If the system property is not set, the default is 5. (This is much lower than the JDK default of 20, but I don't see the value of following so many redirects.) * this can be overwritten by a http.maxRedirects git config setting. The JGit http.* git config settings are currently all global; JGit has no support yet for URI-specific settings "http.<pattern>.name". Adding support for that is well beyond the scope of this change. Like git-core, we log every redirect attempt (LOG.info) so that users may know about the redirection having occurred. Extends the test framework to configure an AppServer with HTTPS support so that we can test cloning via HTTPS and redirections involving HTTPS. [1] https://git-scm.com/docs/git-config [2] https://kernel.googlesource.com/pub/scm/git/git/+/6628eb41db5189c0cdfdced6d8697e7c813c5f0f [3] https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html CQ: 13987 Bug: 465167 Change-Id: I86518cb76842f7d326b51f8715e3bbf8ada89859 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
9 years ago
Add support to follow HTTP redirects git-core follows HTTP redirects so JGit should also provide this. Implement config setting http.followRedirects with possible values "false" (= never), "true" (= always), and "initial" (only on GET, but not on POST).[1] We must do our own redirect handling and cannot rely on the support that the underlying real connection may offer. At least the JDK's HttpURLConnection has two features that get in the way: * it does not allow cross-protocol redirects and thus fails on http->https redirects (for instance, on Github). * it translates a redirect after a POST to a GET unless the system property "http.strictPostRedirect" is set to true. We don't want to manipulate that system setting nor require it. Additionally, git has its own rules about what redirects it accepts;[2] for instance, it does not allow a redirect that adds query arguments. We handle response codes 301, 302, 303, and 307 as per RFC 2616.[3] On POST we do not handle 303, and we follow redirects only if http.followRedirects == true. Redirects are followed only a certain number of times. There are two ways to control that limit: * by default, the limit is given by the http.maxRedirects system property that is also used by the JDK. If the system property is not set, the default is 5. (This is much lower than the JDK default of 20, but I don't see the value of following so many redirects.) * this can be overwritten by a http.maxRedirects git config setting. The JGit http.* git config settings are currently all global; JGit has no support yet for URI-specific settings "http.<pattern>.name". Adding support for that is well beyond the scope of this change. Like git-core, we log every redirect attempt (LOG.info) so that users may know about the redirection having occurred. Extends the test framework to configure an AppServer with HTTPS support so that we can test cloning via HTTPS and redirections involving HTTPS. [1] https://git-scm.com/docs/git-config [2] https://kernel.googlesource.com/pub/scm/git/git/+/6628eb41db5189c0cdfdced6d8697e7c813c5f0f [3] https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html CQ: 13987 Bug: 465167 Change-Id: I86518cb76842f7d326b51f8715e3bbf8ada89859 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
9 years ago
Add support to follow HTTP redirects git-core follows HTTP redirects so JGit should also provide this. Implement config setting http.followRedirects with possible values "false" (= never), "true" (= always), and "initial" (only on GET, but not on POST).[1] We must do our own redirect handling and cannot rely on the support that the underlying real connection may offer. At least the JDK's HttpURLConnection has two features that get in the way: * it does not allow cross-protocol redirects and thus fails on http->https redirects (for instance, on Github). * it translates a redirect after a POST to a GET unless the system property "http.strictPostRedirect" is set to true. We don't want to manipulate that system setting nor require it. Additionally, git has its own rules about what redirects it accepts;[2] for instance, it does not allow a redirect that adds query arguments. We handle response codes 301, 302, 303, and 307 as per RFC 2616.[3] On POST we do not handle 303, and we follow redirects only if http.followRedirects == true. Redirects are followed only a certain number of times. There are two ways to control that limit: * by default, the limit is given by the http.maxRedirects system property that is also used by the JDK. If the system property is not set, the default is 5. (This is much lower than the JDK default of 20, but I don't see the value of following so many redirects.) * this can be overwritten by a http.maxRedirects git config setting. The JGit http.* git config settings are currently all global; JGit has no support yet for URI-specific settings "http.<pattern>.name". Adding support for that is well beyond the scope of this change. Like git-core, we log every redirect attempt (LOG.info) so that users may know about the redirection having occurred. Extends the test framework to configure an AppServer with HTTPS support so that we can test cloning via HTTPS and redirections involving HTTPS. [1] https://git-scm.com/docs/git-config [2] https://kernel.googlesource.com/pub/scm/git/git/+/6628eb41db5189c0cdfdced6d8697e7c813c5f0f [3] https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html CQ: 13987 Bug: 465167 Change-Id: I86518cb76842f7d326b51f8715e3bbf8ada89859 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
9 years ago
Add support to follow HTTP redirects git-core follows HTTP redirects so JGit should also provide this. Implement config setting http.followRedirects with possible values "false" (= never), "true" (= always), and "initial" (only on GET, but not on POST).[1] We must do our own redirect handling and cannot rely on the support that the underlying real connection may offer. At least the JDK's HttpURLConnection has two features that get in the way: * it does not allow cross-protocol redirects and thus fails on http->https redirects (for instance, on Github). * it translates a redirect after a POST to a GET unless the system property "http.strictPostRedirect" is set to true. We don't want to manipulate that system setting nor require it. Additionally, git has its own rules about what redirects it accepts;[2] for instance, it does not allow a redirect that adds query arguments. We handle response codes 301, 302, 303, and 307 as per RFC 2616.[3] On POST we do not handle 303, and we follow redirects only if http.followRedirects == true. Redirects are followed only a certain number of times. There are two ways to control that limit: * by default, the limit is given by the http.maxRedirects system property that is also used by the JDK. If the system property is not set, the default is 5. (This is much lower than the JDK default of 20, but I don't see the value of following so many redirects.) * this can be overwritten by a http.maxRedirects git config setting. The JGit http.* git config settings are currently all global; JGit has no support yet for URI-specific settings "http.<pattern>.name". Adding support for that is well beyond the scope of this change. Like git-core, we log every redirect attempt (LOG.info) so that users may know about the redirection having occurred. Extends the test framework to configure an AppServer with HTTPS support so that we can test cloning via HTTPS and redirections involving HTTPS. [1] https://git-scm.com/docs/git-config [2] https://kernel.googlesource.com/pub/scm/git/git/+/6628eb41db5189c0cdfdced6d8697e7c813c5f0f [3] https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html CQ: 13987 Bug: 465167 Change-Id: I86518cb76842f7d326b51f8715e3bbf8ada89859 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
9 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373
  1. /*
  2. * Copyright (C) 2013, 2017 Christian Halstrick <christian.halstrick@sap.com>
  3. * and other copyright owners as documented in the project's IP log.
  4. *
  5. * This program and the accompanying materials are made available
  6. * under the terms of the Eclipse Distribution License v1.0 which
  7. * accompanies this distribution, is reproduced below, and is
  8. * available at http://www.eclipse.org/org/documents/edl-v10.php
  9. *
  10. * All rights reserved.
  11. *
  12. * Redistribution and use in source and binary forms, with or
  13. * without modification, are permitted provided that the following
  14. * conditions are met:
  15. *
  16. * - Redistributions of source code must retain the above copyright
  17. * notice, this list of conditions and the following disclaimer.
  18. *
  19. * - Redistributions in binary form must reproduce the above
  20. * copyright notice, this list of conditions and the following
  21. * disclaimer in the documentation and/or other materials provided
  22. * with the distribution.
  23. *
  24. * - Neither the name of the Eclipse Foundation, Inc. nor the
  25. * names of its contributors may be used to endorse or promote
  26. * products derived from this software without specific prior
  27. * written permission.
  28. *
  29. * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
  30. * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
  31. * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  32. * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  33. * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
  34. * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  35. * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  36. * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  37. * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
  38. * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  39. * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  40. * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
  41. * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  42. */
  43. package org.eclipse.jgit.transport.http;
  44. import java.io.IOException;
  45. import java.io.InputStream;
  46. import java.io.OutputStream;
  47. import java.net.HttpURLConnection;
  48. import java.net.ProtocolException;
  49. import java.net.URL;
  50. import java.security.KeyManagementException;
  51. import java.security.NoSuchAlgorithmException;
  52. import java.security.SecureRandom;
  53. import java.util.List;
  54. import java.util.Map;
  55. import javax.net.ssl.HostnameVerifier;
  56. import javax.net.ssl.KeyManager;
  57. import javax.net.ssl.TrustManager;
  58. import org.eclipse.jgit.annotations.NonNull;
  59. /**
  60. * The interface of connections used during HTTP communication. This interface
  61. * is that subset of the interface exposed by {@link java.net.HttpURLConnection}
  62. * which is used by JGit
  63. *
  64. * @since 3.3
  65. */
  66. public interface HttpConnection {
  67. /**
  68. * @see HttpURLConnection#HTTP_OK
  69. */
  70. int HTTP_OK = java.net.HttpURLConnection.HTTP_OK;
  71. /**
  72. * @see HttpURLConnection#HTTP_MOVED_PERM
  73. * @since 4.7
  74. */
  75. int HTTP_MOVED_PERM = java.net.HttpURLConnection.HTTP_MOVED_PERM;
  76. /**
  77. * @see HttpURLConnection#HTTP_MOVED_TEMP
  78. * @since 4.9
  79. */
  80. int HTTP_MOVED_TEMP = java.net.HttpURLConnection.HTTP_MOVED_TEMP;
  81. /**
  82. * @see HttpURLConnection#HTTP_SEE_OTHER
  83. * @since 4.9
  84. */
  85. int HTTP_SEE_OTHER = java.net.HttpURLConnection.HTTP_SEE_OTHER;
  86. /**
  87. * HTTP 1.1 additional MOVED_TEMP status code; value = 307.
  88. *
  89. * @see #HTTP_MOVED_TEMP
  90. * @since 4.9
  91. */
  92. int HTTP_11_MOVED_TEMP = 307;
  93. /**
  94. * @see HttpURLConnection#HTTP_NOT_FOUND
  95. */
  96. int HTTP_NOT_FOUND = java.net.HttpURLConnection.HTTP_NOT_FOUND;
  97. /**
  98. * @see HttpURLConnection#HTTP_UNAUTHORIZED
  99. */
  100. int HTTP_UNAUTHORIZED = java.net.HttpURLConnection.HTTP_UNAUTHORIZED;
  101. /**
  102. * @see HttpURLConnection#HTTP_FORBIDDEN
  103. */
  104. int HTTP_FORBIDDEN = java.net.HttpURLConnection.HTTP_FORBIDDEN;
  105. /**
  106. * Get response code
  107. *
  108. * @see HttpURLConnection#getResponseCode()
  109. * @return the HTTP Status-Code, or -1
  110. * @throws java.io.IOException
  111. */
  112. int getResponseCode() throws IOException;
  113. /**
  114. * Get URL
  115. *
  116. * @see HttpURLConnection#getURL()
  117. * @return the URL.
  118. */
  119. URL getURL();
  120. /**
  121. * Get response message
  122. *
  123. * @see HttpURLConnection#getResponseMessage()
  124. * @return the HTTP response message, or <code>null</code>
  125. * @throws java.io.IOException
  126. */
  127. String getResponseMessage() throws IOException;
  128. /**
  129. * Get map of header fields
  130. *
  131. * @see HttpURLConnection#getHeaderFields()
  132. * @return a Map of header fields
  133. */
  134. Map<String, List<String>> getHeaderFields();
  135. /**
  136. * Set request property
  137. *
  138. * @see HttpURLConnection#setRequestProperty(String, String)
  139. * @param key
  140. * the keyword by which the request is known (e.g., "
  141. * <code>Accept</code>").
  142. * @param value
  143. * the value associated with it.
  144. */
  145. void setRequestProperty(String key, String value);
  146. /**
  147. * Set request method
  148. *
  149. * @see HttpURLConnection#setRequestMethod(String)
  150. * @param method
  151. * the HTTP method
  152. * @exception ProtocolException
  153. * if the method cannot be reset or if the requested method
  154. * isn't valid for HTTP.
  155. * @throws java.net.ProtocolException
  156. * if any.
  157. */
  158. void setRequestMethod(String method)
  159. throws ProtocolException;
  160. /**
  161. * Set if to use caches
  162. *
  163. * @see HttpURLConnection#setUseCaches(boolean)
  164. * @param usecaches
  165. * a <code>boolean</code> indicating whether or not to allow
  166. * caching
  167. */
  168. void setUseCaches(boolean usecaches);
  169. /**
  170. * Set connect timeout
  171. *
  172. * @see HttpURLConnection#setConnectTimeout(int)
  173. * @param timeout
  174. * an <code>int</code> that specifies the connect timeout value
  175. * in milliseconds
  176. */
  177. void setConnectTimeout(int timeout);
  178. /**
  179. * Set read timeout
  180. *
  181. * @see HttpURLConnection#setReadTimeout(int)
  182. * @param timeout
  183. * an <code>int</code> that specifies the timeout value to be
  184. * used in milliseconds
  185. */
  186. void setReadTimeout(int timeout);
  187. /**
  188. * Get content type
  189. *
  190. * @see HttpURLConnection#getContentType()
  191. * @return the content type of the resource that the URL references, or
  192. * <code>null</code> if not known.
  193. */
  194. String getContentType();
  195. /**
  196. * Get input stream
  197. *
  198. * @see HttpURLConnection#getInputStream()
  199. * @return an input stream that reads from this open connection.
  200. * @exception IOException
  201. * if an I/O error occurs while creating the input stream.
  202. * @throws java.io.IOException
  203. * if any.
  204. */
  205. InputStream getInputStream() throws IOException;
  206. /**
  207. * Get header field. According to
  208. * {@link <a href="https://tools.ietf.org/html/rfc2616#section-4.2">RFC
  209. * 2616</a>} header field names are case insensitive. Header fields defined
  210. * as a comma separated list can have multiple header fields with the same
  211. * field name. This method only returns one of these header fields. If you
  212. * want the union of all values of all multiple header fields with the same
  213. * field name then use {@link #getHeaderFields(String)}
  214. *
  215. * @see HttpURLConnection#getHeaderField(String)
  216. * @param name
  217. * the name of a header field.
  218. * @return the value of the named header field, or <code>null</code> if
  219. * there is no such field in the header.
  220. */
  221. String getHeaderField(@NonNull String name);
  222. /**
  223. * Get all values of given header field. According to
  224. * {@link <a href="https://tools.ietf.org/html/rfc2616#section-4.2">RFC
  225. * 2616</a>} header field names are case insensitive. Header fields defined
  226. * as a comma separated list can have multiple header fields with the same
  227. * field name. This method does not validate if the given header field is
  228. * defined as a comma separated list.
  229. *
  230. * @param name
  231. * the name of a header field.
  232. * @return the list of values of the named header field
  233. * @since 5.2
  234. */
  235. List<String> getHeaderFields(@NonNull String name);
  236. /**
  237. * Get content length
  238. *
  239. * @see HttpURLConnection#getContentLength()
  240. * @return the content length of the resource that this connection's URL
  241. * references, {@code -1} if the content length is not known, or if
  242. * the content length is greater than Integer.MAX_VALUE.
  243. */
  244. int getContentLength();
  245. /**
  246. * Set whether or not to follow HTTP redirects.
  247. *
  248. * @see HttpURLConnection#setInstanceFollowRedirects(boolean)
  249. * @param followRedirects
  250. * a <code>boolean</code> indicating whether or not to follow
  251. * HTTP redirects.
  252. */
  253. void setInstanceFollowRedirects(boolean followRedirects);
  254. /**
  255. * Set if to do output
  256. *
  257. * @see HttpURLConnection#setDoOutput(boolean)
  258. * @param dooutput
  259. * the new value.
  260. */
  261. void setDoOutput(boolean dooutput);
  262. /**
  263. * Set fixed length streaming mode
  264. *
  265. * @see HttpURLConnection#setFixedLengthStreamingMode(int)
  266. * @param contentLength
  267. * The number of bytes which will be written to the OutputStream.
  268. */
  269. void setFixedLengthStreamingMode(int contentLength);
  270. /**
  271. * Get output stream
  272. *
  273. * @see HttpURLConnection#getOutputStream()
  274. * @return an output stream that writes to this connection.
  275. * @throws java.io.IOException
  276. */
  277. OutputStream getOutputStream() throws IOException;
  278. /**
  279. * Set chunked streaming mode
  280. *
  281. * @see HttpURLConnection#setChunkedStreamingMode(int)
  282. * @param chunklen
  283. * The number of bytes to write in each chunk. If chunklen is
  284. * less than or equal to zero, a default value will be used.
  285. */
  286. void setChunkedStreamingMode(int chunklen);
  287. /**
  288. * Get request method
  289. *
  290. * @see HttpURLConnection#getRequestMethod()
  291. * @return the HTTP request method
  292. */
  293. String getRequestMethod();
  294. /**
  295. * Whether we use a proxy
  296. *
  297. * @see HttpURLConnection#usingProxy()
  298. * @return a boolean indicating if the connection is using a proxy.
  299. */
  300. boolean usingProxy();
  301. /**
  302. * Connect
  303. *
  304. * @see HttpURLConnection#connect()
  305. * @throws java.io.IOException
  306. */
  307. void connect() throws IOException;
  308. /**
  309. * Configure the connection so that it can be used for https communication.
  310. *
  311. * @param km
  312. * the keymanager managing the key material used to authenticate
  313. * the local SSLSocket to its peer
  314. * @param tm
  315. * the trustmanager responsible for managing the trust material
  316. * that is used when making trust decisions, and for deciding
  317. * whether credentials presented by a peer should be accepted.
  318. * @param random
  319. * the source of randomness for this generator or null. See
  320. * {@link javax.net.ssl.SSLContext#init(KeyManager[], TrustManager[], SecureRandom)}
  321. * @throws java.security.NoSuchAlgorithmException
  322. * @throws java.security.KeyManagementException
  323. */
  324. void configure(KeyManager[] km, TrustManager[] tm,
  325. SecureRandom random) throws NoSuchAlgorithmException,
  326. KeyManagementException;
  327. /**
  328. * Set the {@link javax.net.ssl.HostnameVerifier} used during https
  329. * communication
  330. *
  331. * @param hostnameverifier
  332. * a {@link javax.net.ssl.HostnameVerifier} object.
  333. * @throws java.security.NoSuchAlgorithmException
  334. * @throws java.security.KeyManagementException
  335. */
  336. void setHostnameVerifier(HostnameVerifier hostnameverifier)
  337. throws NoSuchAlgorithmException, KeyManagementException;
  338. }