httprequest httpurlconnection - Come utilizzare java.net.URLConnection per attivare e gestire le richieste HTTP

^{Innanzitutto una dichiarazione di non responsabilità: i frammenti di codice pubblicati sono tutti esempi di base. Dovrai gestire banali IOException e RuntimeException come NullPointerException , ArrayIndexOutOfBoundsException e ti ArrayIndexOutOfBoundsException .}

Preparazione

Per prima cosa dobbiamo conoscere almeno l'URL e il set di caratteri. I parametri sono opzionali e dipendono dai requisiti funzionali.

String url = "http://example.com";
String charset = "UTF-8";  // Or in Java 7 and later, use the constant: java.nio.charset.StandardCharsets.UTF_8.name()
String param1 = "value1";
String param2 = "value2";
// ...

String query = String.format("param1=%s&param2=%s", 
     URLEncoder.encode(param1, charset), 
     URLEncoder.encode(param2, charset));

I parametri della query devono essere in formato name=value ed essere concatenati da & . Normalmente, inoltre URL-encode l' URL-encode dei parametri di query con il set di caratteri specificato utilizzando URLEncoder#encode() .

^{Il String#format() è solo per comodità. Lo preferisco quando avrei bisogno dell'operatore di concatenazione delle stringhe + più di due volte.}

Esecuzione di una richiesta HTTP GET con (facoltativamente) parametri di query

È un compito banale. È il metodo di richiesta predefinito.

URLConnection connection = new URL(url + "?" + query).openConnection();
connection.setRequestProperty("Accept-Charset", charset);
InputStream response = connection.getInputStream();
// ...

Qualsiasi stringa di query dovrebbe essere concatenata all'URL usando ? . L'intestazione Accept-Charset può suggerire al server la codifica dei parametri. Se non si invia alcuna stringa di query, è possibile lasciare l'intestazione Accept-Charset distanza. Se non hai bisogno di impostare alcuna intestazione, puoi anche utilizzare il metodo di scelta rapida URL#openStream() .

InputStream response = new URL(url).openStream();
// ...

In entrambi i casi, se l'altro lato è un HttpServlet , verrà chiamato il suo metodo doGet() e i parametri saranno disponibili da HttpServletRequest#getParameter() .

A scopo di test, è possibile stampare il corpo della risposta su stdout come di seguito:

try (Scanner scanner = new Scanner(response)) {
    String responseBody = scanner.useDelimiter("\\A").next();
    System.out.println(responseBody);
}

Esecuzione di una richiesta POST HTTP con parametri di query

Impostando il numero di URLConnection#setDoOutput() su true imposta in modo implicito il metodo di richiesta su POST. Il POST HTTP standard come form Web è di tipo application/x-www-form-urlencoded cui la stringa di query viene scritta nel corpo della richiesta.

URLConnection connection = new URL(url).openConnection();
connection.setDoOutput(true); // Triggers POST.
connection.setRequestProperty("Accept-Charset", charset);
connection.setRequestProperty("Content-Type", "application/x-www-form-urlencoded;charset=" + charset);

try (OutputStream output = connection.getOutputStream()) {
    output.write(query.getBytes(charset));
}

InputStream response = connection.getInputStream();
// ...

Nota: ogni volta che desideri inviare un modulo HTML a livello di codice, non dimenticare di prendere le coppie name=value di qualsiasi elemento <input type="hidden"> nella stringa di query e, naturalmente, anche la coppia name=value di l'elemento <input type="submit"> che vorresti "premere" a livello di codice (perché di solito è usato sul lato server per distinguere se un pulsante è stato premuto e, in tal caso, quale).

Puoi anche java.net.URLConnection l' java.net.URLConnection ottenuto a HttpURLConnection e usare invece HttpURLConnection#setRequestMethod() . Ma se stai cercando di utilizzare la connessione per l'output, devi comunque impostare URLConnection#setDoOutput() su true .

HttpURLConnection httpConnection = (HttpURLConnection) new URL(url).openConnection();
httpConnection.setRequestMethod("POST");
// ...

In entrambi i casi, se l'altro lato è un HttpServlet , verrà chiamato il suo metodo doPost() e i parametri saranno disponibili da HttpServletRequest#getParameter() .

Attiva effettivamente la richiesta HTTP

È possibile URLConnection#connect() esplicitamente la richiesta HTTP con URLConnection#connect() , ma la richiesta verrà automaticamente URLConnection#connect() su richiesta quando si desidera ottenere qualsiasi informazione sulla risposta HTTP, ad esempio il corpo della risposta utilizzando URLConnection#getInputStream() e così via. Gli esempi sopra fanno esattamente questo, quindi la chiamata connect() è in effetti superflua.

Raccolta di informazioni sulla risposta HTTP

1. Stato della risposta HTTP :

   Hai bisogno di un HttpURLConnection qui. Provalo prima se necessario.

   int status = httpConnection.getResponseCode();
   

2. Intestazioni di risposta HTTP :

   for (Entry<String, List<String>> header : connection.getHeaderFields().entrySet()) {
       System.out.println(header.getKey() + "=" + header.getValue());
   }
   

3. Codifica della risposta HTTP :

   Quando Content-Type contiene un parametro charset , il corpo della risposta è probabilmente basato sul testo e vorremmo elaborare il corpo della risposta con la codifica dei caratteri specificata sul lato server.

   String contentType = connection.getHeaderField("Content-Type");
   String charset = null;
   
   for (String param : contentType.replace(" ", "").split(";")) {
       if (param.startsWith("charset=")) {
           charset = param.split("=", 2)[1];
           break;
       }
   }
   
   if (charset != null) {
       try (BufferedReader reader = new BufferedReader(new InputStreamReader(response, charset))) {
           for (String line; (line = reader.readLine()) != null;) {
               // ... System.out.println(line) ?
           }
       }
   } else {
       // It's likely binary content, use InputStream/OutputStream.
   }
   

Mantenimento della sessione

La sessione lato server è solitamente supportata da un cookie. Alcuni moduli Web richiedono l'accesso e / o il tracciamento di una sessione. È possibile utilizzare l'API CookieHandler per conservare i cookie. È necessario preparare un CookieManager con una CookiePolicy di ACCEPT_ALL prima di inviare tutte le richieste HTTP.

// First set the default cookie manager.
CookieHandler.setDefault(new CookieManager(null, CookiePolicy.ACCEPT_ALL));

// All the following subsequent URLConnections will use the same cookie manager.
URLConnection connection = new URL(url).openConnection();
// ...

connection = new URL(url).openConnection();
// ...

connection = new URL(url).openConnection();
// ...

Si noti che questo è noto non sempre funziona correttamente in tutte le circostanze. Se fallisce per te, allora è meglio raccogliere e impostare manualmente le intestazioni dei cookie. Fondamentalmente è necessario prendere tutte le intestazioni Set-Cookie dalla risposta del login o dalla prima richiesta GET e quindi passare questo attraverso le richieste successive.

// Gather all cookies on the first request.
URLConnection connection = new URL(url).openConnection();
List<String> cookies = connection.getHeaderFields().get("Set-Cookie");
// ...

// Then use the same cookies on all subsequent requests.
connection = new URL(url).openConnection();
for (String cookie : cookies) {
    connection.addRequestProperty("Cookie", cookie.split(";", 2)[0]);
}
// ...

Lo split(";", 2)[0] è lì per sbarazzarsi degli attributi dei cookie che sono irrilevanti per il lato server come expires , path , ecc. In alternativa, puoi anche usare cookie.substring(0, cookie.indexOf(';')) invece di split() .

Modalità di streaming

HttpURLConnection l' intero corpo della richiesta prima di inviarlo effettivamente, indipendentemente dal fatto che tu abbia impostato una lunghezza del contenuto fissa usando connection.setRequestProperty("Content-Length", contentLength); . Ciò può causare OutOfMemoryException s ogniqualvolta si inviano contemporaneamente richieste POST di grandi dimensioni (ad es. Caricamento di file). Per evitare ciò, si desidera impostare HttpURLConnection#setFixedLengthStreamingMode() .

httpConnection.setFixedLengthStreamingMode(contentLength);

Ma se la lunghezza del contenuto non è realmente nota in anticipo, è possibile utilizzare la modalità di streaming chunked impostando HttpURLConnection#setChunkedStreamingMode() conseguenza. Questo imposterà l'header HTTP Transfer-Encoding su chunked che costringerà il corpo della richiesta ad essere inviato in blocchi. L'esempio seguente invierà il corpo in blocchi di 1 KB.

httpConnection.setChunkedStreamingMode(1024);

User-Agent

Può succedere che una richiesta restituisca una risposta inaspettata, mentre funziona perfettamente con un vero browser web . Il lato server probabilmente blocca le richieste in base all'intestazione della richiesta User-Agent . URLConnection lo URLConnection di default su Java/1.6.0_19 dove l'ultima parte è ovviamente la versione di JRE. È possibile ignorare questo come segue:

connection.setRequestProperty("User-Agent", "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36"); // Do as if you're using Chrome 41 on Windows 7.

Utilizzare la stringa User-Agent da un browser recente .

Gestione degli errori

Se il codice di risposta HTTP è 4nn (errore client) o 5nn (errore server), è possibile leggere HttpURLConnection#getErrorStream() per verificare se il server ha inviato informazioni utili sull'errore.

InputStream error = ((HttpURLConnection) connection).getErrorStream();

Se il codice di risposta HTTP è -1, qualcosa è andato storto con la gestione della connessione e della risposta. L'implementazione HttpURLConnection è nei vecchi JRE un po 'buggy con il mantenimento delle connessioni in vita. Si consiglia di disattivarlo impostando la proprietà di sistema http.keepAlive su false . Puoi farlo a livello di codice all'inizio della tua applicazione:

System.setProperty("http.keepAlive", "false");

Caricamento di file

Normalmente utilizzerai multipart/form-data codifica multipart/form-data per contenuti POST misti (dati binari e di carattere). La codifica è più in dettaglio descritta nella RFC2388 .

String param = "value";
File textFile = new File("/path/to/file.txt");
File binaryFile = new File("/path/to/file.bin");
String boundary = Long.toHexString(System.currentTimeMillis()); // Just generate some unique random value.
String CRLF = "\r\n"; // Line separator required by multipart/form-data.
URLConnection connection = new URL(url).openConnection();
connection.setDoOutput(true);
connection.setRequestProperty("Content-Type", "multipart/form-data; boundary=" + boundary);

try (
    OutputStream output = connection.getOutputStream();
    PrintWriter writer = new PrintWriter(new OutputStreamWriter(output, charset), true);
) {
    // Send normal param.
    writer.append("--" + boundary).append(CRLF);
    writer.append("Content-Disposition: form-data; name=\"param\"").append(CRLF);
    writer.append("Content-Type: text/plain; charset=" + charset).append(CRLF);
    writer.append(CRLF).append(param).append(CRLF).flush();

    // Send text file.
    writer.append("--" + boundary).append(CRLF);
    writer.append("Content-Disposition: form-data; name=\"textFile\"; filename=\"" + textFile.getName() + "\"").append(CRLF);
    writer.append("Content-Type: text/plain; charset=" + charset).append(CRLF); // Text file itself must be saved in this charset!
    writer.append(CRLF).flush();
    Files.copy(textFile.toPath(), output);
    output.flush(); // Important before continuing with writer!
    writer.append(CRLF).flush(); // CRLF is important! It indicates end of boundary.

    // Send binary file.
    writer.append("--" + boundary).append(CRLF);
    writer.append("Content-Disposition: form-data; name=\"binaryFile\"; filename=\"" + binaryFile.getName() + "\"").append(CRLF);
    writer.append("Content-Type: " + URLConnection.guessContentTypeFromName(binaryFile.getName())).append(CRLF);
    writer.append("Content-Transfer-Encoding: binary").append(CRLF);
    writer.append(CRLF).flush();
    Files.copy(binaryFile.toPath(), output);
    output.flush(); // Important before continuing with writer!
    writer.append(CRLF).flush(); // CRLF is important! It indicates end of boundary.

    // End of multipart/form-data.
    writer.append("--" + boundary + "--").append(CRLF).flush();
}

Se l'altro lato è un HttpServlet , verrà chiamato il suo metodo doPost() e le parti saranno disponibili da HttpServletRequest#getPart() (nota, quindi non getParameter() e così via!). Il metodo getPart() è tuttavia relativamente nuovo, è introdotto in Servlet 3.0 (Glassfish 3, Tomcat 7, ecc.). Prima di Servlet 3.0, la scelta migliore è usare Apache Commons FileUpload per analizzare una richiesta multipart/form-data . Vedi anche questa risposta per esempi di entrambi gli approcci FileUpload e Servelt 3.0.

Gestione di siti HTTPS non affidabili o mal configurati

A volte devi connettere un URL HTTPS, forse perché stai scrivendo un web raschietto. In tal caso, è probabile che tu abbia a che fare con un javax.net.ssl.SSLException: Not trusted server certificate su alcuni siti HTTPS che non mantengono aggiornati i loro certificati SSL, o un java.security.cert.CertificateException: No subject alternative DNS name matching [hostname] found o javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name su alcuni siti HTTPS configurati in modo errato.

Il seguente inizializzatore static una sola volta nella classe di raschiatura Web dovrebbe rendere HttpsURLConnection più indulgente rispetto a quei siti HTTPS e quindi non generare più tali eccezioni.

static {
    TrustManager[] trustAllCertificates = new TrustManager[] {
        new X509TrustManager() {
            @Override
            public X509Certificate[] getAcceptedIssuers() {
                return null; // Not relevant.
            }
            @Override
            public void checkClientTrusted(X509Certificate[] certs, String authType) {
                // Do nothing. Just allow them all.
            }
            @Override
            public void checkServerTrusted(X509Certificate[] certs, String authType) {
                // Do nothing. Just allow them all.
            }
        }
    };

    HostnameVerifier trustAllHostnames = new HostnameVerifier() {
        @Override
        public boolean verify(String hostname, SSLSession session) {
            return true; // Just allow them all.
        }
    };

    try {
        System.setProperty("jsse.enableSNIExtension", "false");
        SSLContext sc = SSLContext.getInstance("SSL");
        sc.init(null, trustAllCertificates, new SecureRandom());
        HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
        HttpsURLConnection.setDefaultHostnameVerifier(trustAllHostnames);
    }
    catch (GeneralSecurityException e) {
        throw new ExceptionInInitializerError(e);
    }
}

Ultime parole

L' HttpClient di HttpComponents di Apache è molto più conveniente in tutto questo :)

• HttpClient Tutorial
• Esempi di HttpClient

Analisi ed estrazione di HTML

Se tutto ciò che vuoi è analizzare ed estrarre dati da HTML, meglio usare un parser HTML come Jsoup

• Quali sono i pro / contro dei principali parser HTML in Java
• Come eseguire la scansione ed estrarre una pagina Web in Java

Inizialmente sono stato ingannato da questo article che favorisce HttpClient .

Più tardi mi sono reso conto che HttpURLConnection rimarrà da questo article

Come per il blog di Google :

Il client HTTP Apache ha meno bug su Eclair e Froyo. È la scelta migliore per queste versioni. Per Gingerbread, HttpURLConnection è la scelta migliore. La sua semplice API e le ridotte dimensioni lo rendono perfetto per Android.

La compressione trasparente e la cache di risposta riducono l'utilizzo della rete, migliorano la velocità e fanno risparmiare batteria. Le nuove applicazioni dovrebbero usare HttpURLConnection; è dove andremo a spendere le nostre energie andando avanti.

Dopo aver letto rapidvaluesolutions.com/tech_blog/… e qualche altra domanda sul flusso, sono convinto che HttpURLConnection rimarrà per durate più lunghe.

Alcune delle domande di SE che favoriscono HttpURLConnections :

Su Android, effettua una richiesta POST con i dati del modulo codificato URL senza utilizzare UrlEncodedFormEntity

HttpPost funziona nel progetto Java, non in Android

Ti suggerisco di dare un'occhiata al codice su kevinsawicki/http-request , è fondamentalmente un wrapper su HttpUrlConnection fornisce un'API molto più semplice nel caso in cui desideri semplicemente effettuare le richieste in questo momento o puoi dare un'occhiata alle fonti (non è troppo grande) per dare un'occhiata a come vengono gestite le connessioni.

Esempio: creare una richiesta GET con tipo di contenuto application/json e alcuni parametri di query:

// GET http://google.com?q=baseball%20gloves&size=100
String response = HttpRequest.get("http://google.com", true, "q", "baseball gloves", "size", 100)
        .accept("application/json")
        .body();
System.out.println("Response was: " + response);

Quando si lavora con HTTP è quasi sempre più utile riferirsi a HttpURLConnection piuttosto che alla classe base URLConnection (dato che URLConnection è una classe astratta quando si richiede URLConnection.openConnection() su un URL HTTP che è quello che si otterrà comunque).

Quindi, invece di fare affidamento su URLConnection#setDoOutput(true) per impostare implicitamente il metodo di richiesta su POST, invece, fare httpURLConnection.setRequestMethod("POST") che alcuni potrebbero trovare più naturali (e che consente anche di specificare altri metodi di richiesta come PUT , DELETE , ...).

Fornisce anche utili costanti HTTP in modo che tu possa fare:

int responseCode = httpURLConnection.getResponseCode();

if (responseCode == HttpURLConnection.HTTP_OK) {

Ispirato da questa e da altre domande su SO, ho creato un minimo basic-http-client open source minimale che incarna la maggior parte delle tecniche trovate qui.

google-http-java-client è anche una grande risorsa open source.

se si utilizza http, si prega di rimuovere questa riga

urlConnection.setDoOutput(true);

Puoi anche utilizzare JdkRequest da jcabi-http (sono uno sviluppatore), che fa tutto questo per te, decorando HttpURLConnection, attivando le richieste HTTP e le risposte di analisi, ad esempio:

String html = new JdkRequest("http://www.google.com").fetch().body();

Controlla questo post sul blog per maggiori informazioni: http://www.yegor256.com/2014/04/11/jcabi-http-intro.html

Ci sono 2 opzioni che puoi utilizzare con gli hit URL HTTP: GET / POST

Richiesta GET: -

HttpURLConnection.setFollowRedirects(true); // defaults to true

String url = "https://name_of_the_url";
URL request_url = new URL(url);
HttpURLConnection http_conn = (HttpURLConnection)request_url.openConnection();
http_conn.setConnectTimeout(100000);
http_conn.setReadTimeout(100000);
http_conn.setInstanceFollowRedirects(true);
System.out.println(String.valueOf(http_conn.getResponseCode()));

Richiesta POST: -

HttpURLConnection.setFollowRedirects(true); // defaults to true

String url = "https://name_of_the_url"
URL request_url = new URL(url);
HttpURLConnection http_conn = (HttpURLConnection)request_url.openConnection();
http_conn.setConnectTimeout(100000);
http_conn.setReadTimeout(100000);
http_conn.setInstanceFollowRedirects(true);
http_conn.setDoOutput(true);
PrintWriter out = new PrintWriter(http_conn.getOutputStream());
if (urlparameter != null) {
   out.println(urlparameter);
}
out.close();
out = null;
System.out.println(String.valueOf(http_conn.getResponseCode()));

Poiché la domanda si approfondisce se DELETE "dovrebbe" restituire 200 vs 204 , vale la pena considerare che alcune persone consigliano di restituire un'entità con collegamenti, quindi la preferenza è 200 .

"Invece di restituire 204 (nessun contenuto), l'API dovrebbe essere utile e suggerire i luoghi da visitare.In questo esempio penso che un collegamento ovvio da fornire sia" "somewhere.com/container/" (meno 'risorsa') "- il contenitore da cui il client ha appena eliminato una risorsa. Forse il cliente desidera eliminare più risorse, quindi sarebbe un collegamento utile. "

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

Se un cliente incontra una risposta 204, può rinunciare, andare al punto di ingresso dell'API o tornare alla risorsa precedente visitata. Nessuna delle due opzioni è particolarmente buona.

Personalmente non direi che 204 è sbagliato (né l'autore, dice "fastidioso") perché un buon caching presso il cliente ha molti vantaggi. La cosa migliore è essere coerenti in entrambi i modi.