studio setconnecttimeout example espaƱol java httpurlconnection

setconnecttimeout - java httpurlconnection rest example



URLConnection no sigue redirigir (5)

¿Tiene algo llamado HttpURLConnection.setFollowRedirects(false) por casualidad?

Siempre puedes llamar

conn.setInstanceFollowRedirects(true);

si desea asegurarse de que no afecta el resto del comportamiento de la aplicación.

No puedo entender por qué la HttpURLConnection de Java no sigue a la redirección. Uso el siguiente código para obtener esta página :

import java.net.URL; import java.net.HttpURLConnection; import java.io.InputStream; public class Tester { public static void main(String argv[]) throws Exception{ InputStream is = null; try { String bitlyUrl = "http://bit.ly/4hW294"; URL resourceUrl = new URL(bitlyUrl); HttpURLConnection conn = (HttpURLConnection)resourceUrl.openConnection(); conn.setConnectTimeout(15000); conn.setReadTimeout(15000); conn.setRequestProperty("User-Agent", "Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)"); conn.connect(); is = conn.getInputStream(); String res = conn.getURL().toString(); if (res.toLowerCase().contains("bit.ly")) System.out.println("bit.ly is after resolving: "+res); } catch (Exception e) { System.out.println("error happened: "+e.toString()); } finally { if (is != null) is.close(); } } }

Además, recibo la siguiente respuesta (¡parece absolutamente correcto!):

GET /4hW294 HTTP/1.1 Host: bit.ly Connection: Keep-Alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru-RU; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) HTTP/1.1 301 Moved Server: nginx/0.7.42 Date: Thu, 10 Dec 2009 20:28:44 GMT Content-Type: text/html; charset=utf-8 Connection: keep-alive Location: https://www.myganocafe.com/CafeMacy MIME-Version: 1.0 Content-Length: 297

Lamentablemente, la variable res contiene la misma URL y la secuencia contiene lo siguiente (obviamente, la HttpURLConnection de Java no sigue a la redirección):

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML> <HEAD> <TITLE>Moved</TITLE> </HEAD> <BODY> <H2>Moved</H2> <A HREF="https://www.myganocafe.com/CafeMacy">The requested URL has moved here.</A> <P ALIGN=RIGHT><SMALL><I>AOLserver/4.5.1 on http://127.0.0.1:7400</I></SMALL></P> </BODY> </HTML>


Como mencionaron algunos de ustedes anteriormente, los setFollowRedirect y setInstanceFollowRedirects solo funcionan automáticamente cuando el protocolo redirigido es el mismo. es decir, de http a http y https a https.

setFolloRedirect está a nivel de clase y establece esto para todas las instancias de la conexión de url, mientras que setInstanceFollowRedirects es solo para una instancia determinada. De esta manera, podemos tener un comportamiento diferente para diferentes instancias.

Encontré un muy buen ejemplo aquí http://www.mkyong.com/java/java-httpurlconnection-follow-redirect-example/


HTTPUrlConnection no es responsable de manejar la respuesta del objeto. Es el rendimiento esperado, capta el contenido de la URL solicitada. Depende de usted el usuario de la funcionalidad interpretar la respuesta. No puede leer las intenciones del desarrollador sin especificación.


HttpURLConnection por design no redirigirá automáticamente de HTTP a HTTPS (o viceversa). Seguir el redireccionamiento puede tener serias consecuencias de seguridad. SSL (por lo tanto HTTPS) crea una sesión que es única para el usuario. Esta sesión puede reutilizarse para múltiples solicitudes. Por lo tanto, el servidor puede rastrear todas las solicitudes realizadas desde una sola persona. Esta es una forma débil de identidad y es explotable. Además, el protocolo de enlace SSL puede solicitar el certificado del cliente. Si se envía al servidor, la identidad del cliente se entrega al servidor.

Como señala, supongamos que la aplicación está configurada para realizar autenticación de cliente automáticamente. El usuario espera navegar de forma anónima porque usa HTTP. Pero si su cliente sigue HTTPS sin preguntar, su identidad se revela al servidor.

Con eso entendido, aquí está el código que seguirá los redireccionamientos.

URL resourceUrl, base, next; HttpURLConnection conn; String location; ... while (true) { resourceUrl = new URL(url); conn = (HttpURLConnection) resourceUrl.openConnection(); conn.setConnectTimeout(15000); conn.setReadTimeout(15000); conn.setInstanceFollowRedirects(false); // Make the logic below easier to detect redirections conn.setRequestProperty("User-Agent", "Mozilla/5.0..."); switch (conn.getResponseCode()) { case HttpURLConnection.HTTP_MOVED_PERM: case HttpURLConnection.HTTP_MOVED_TEMP: location = conn.getHeaderField("Location"); location = URLDecoder.decode(location, "UTF-8"); base = new URL(url); next = new URL(base, location); // Deal with relative URLs url = next.toExternalForm(); continue; } break; } is = conn.openStream(); ...


No creo que redirija automáticamente de HTTP a HTTPS (o viceversa).

Aunque sabemos que refleja HTTP, desde el punto de vista del protocolo HTTP, HTTPS es solo otro protocolo completamente diferente y desconocido. Sería inseguro seguir el redireccionamiento sin la aprobación del usuario.

Por ejemplo, supongamos que la aplicación está configurada para realizar autenticación de cliente automáticamente. El usuario espera navegar de forma anónima porque usa HTTP. Pero si su cliente sigue HTTPS sin preguntar, su identidad se revela al servidor.