La URL es accesible con el navegador pero aún así FileNotFoundException con URLConnection

Question

Utilizo una HttpURLConnection para conectarme a un sitio web y recibir un ResponseCode = 404 (HTTP_NOT_FOUND). Sin embargo, no tengo problemas para abrir el sitio web en mi navegador (IE).

¿Por qué la diferencia y qué puedo hacer al respecto?

Saludos, Pavan

Este es mi programa

import java.io.BufferedReader; 
import java.io.InputStreamReader; 
import java.net.HttpURLConnection; 
import java.net.URL; 
import java.net.URLConnection; 

public class TestGet { 
    private static URL source; 

    public static void main(String[] args) { 
     doGet(); 
    } 

    public static void doGet() { 
     try { 
      source = new URL("http://localhost:8080/"); 

      System.out.println("Url is" + source.toString()); 

      URLConnection connection = source.openConnection(); 
      connection.setRequestProperty("User-Agent","Mozilla/5.0 (compatible) "); 
      connection.setRequestProperty("Accept","*/*"); 
      connection.setDoInput(true); 
      connection.setDoOutput(true); 

      System.out.println(((HttpURLConnection) connection).getResponseCode()); 
      BufferedReader rdr = new BufferedReader(new InputStreamReader(
        connection.getInputStream())); 
      StringBuffer b = new StringBuffer(); 
      String line = null; 
      while (true) { 
       line = rdr.readLine(); 
       if (line == null) 
        break; 
       b.append(line); 
      } 

     } catch (Exception e) { 
      e.printStackTrace(); 
      System.err.println(e.toString()); 
     } 
    } 

} 

Seguimiento de la pila

Url ishttp://localhost:8080/ 
404 
java.io.FileNotFoundException: http://localhost:8080/ 
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) 
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) 
    at java.lang.reflect.Constructor.newInstance(Unknown Source) 
    at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source) 
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) 
    at TestGet.doGet(TestGet.java:28) 
    at TestGet.main(TestGet.java:11) 
Caused by: java.io.FileNotFoundException: http://localhost:8080/ 
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) 
    at java.net.HttpURLConnection.getResponseCode(Unknown Source) 
    at TestGet.doGet(TestGet.java:26) 
    ... 1 more 
java.io.FileNotFoundException: http://localhost:8080/ 

Answer 1

Si la URL http://localhost:8080/ se puede acceder bien en el navegador web, el código debería funcionar bien. Ejecuto el programa en mi máquina, funciona bien. Por lo tanto, debe verificar si el servicio del servidor web es correcto.

Answer 2

Aparece el error 404 que significa que no se encuentra la respuesta a la solicitud. Primero debe asegurarse de que haya un servidor que sirve al http://localhost:8080/ y debe devolver algo de contenido con el código 200. De lo contrario, no hay nada que podamos ayudarlo.

La forma más fácil de comprobar si hay algo en la url es pegar la url en la barra de direcciones del navegador y hacer clic en ir. Sin embargo, esto no garantiza que el código Java pueda acceder a él. Por ejemplo, si el servidor está diseñado para la respuesta 404 si no puede encontrar el encabezado del navegador web User-Agent.

Como el servidor devuelve un código de estado, ya sea 200 o 404, significa que este no es un problema de firewall.

De acuerdo con su última edición de la pregunta, puede verla con el navegador web pero no puede descargarla con su código java y el encabezado parece estar configurado correctamente. Sólo hay dos problema que veo:

1. no debe establecer connection.setDoOutput(true); true. Esto forzará la conexión para realizar HTTP POST en lugar de GET y es posible que el servidor no admita POST.

2. Su servidor siempre puede devolver 404 aunque debería haber sido 200. Dado que el navegador web no se preocupa por el estado del error e intenta mostrar todo el contenido para que parezca funcionar desde el navegador web. Si es así, usted debe fijar el servidor para RÉPONSE correctamente en primer lugar, de lo contrario intentar conseguir flujo de error en lugar HttpURLConnection#getErrorStream()

Answer 3

Sé que esto es muy tarde en el juego, pero me hace muy poco teniendo el mismo problema y ninguna de las soluciones aquí trabajadas para mí. En mi caso, en realidad tenía otro proceso ejecutándose en el mismo puerto que estaba robando las solicitudes de la aplicación java. Con la respuesta here de Yair, puede verificar si un proceso se está ejecutando en el mismo puerto como este: En el símbolo del sistema, ejecute netstat -nao | find "8080" en Windows o netstat -nap | grep 8080 en Linux. Debería mostrar una línea con LISTENING y 127.0.0.1:8080 y el siguiente sería el ID del proceso. Simplemente termine el proceso y debería estar listo para continuar.

Answer 4

Tuve un problema similar. Para mí, ayudó a inspeccionar los paquetes usando RawCap. RawCap es uno de los pocos rastreadores de paquetes de Windows que te permite ojear localhost.

En mi caso, el servidor devolvió un 404 debido a un problema de autenticación.

Answer 5

Tuve el problema también. En mi caso, tenía un carácter Unicode invisible en la cadena url. Entonces la conexión no podría abrirlo (FileNotFound lo indica). Lo eliminé y funcionó.

Answer 6

Tuve una situación similar en la que el servicio web procesó las solicitudes POST desde el navegador (en mi caso, Postman, una API probando la extensión de Chrome) pero HttpURLConnection siguió fallando con un 404 para grandes cargas. Supuse erróneamente que el problema debe estar en mi código de cliente HttpURLConnection.

Cuando intenté replicar la solicitud de cUrl con una gran carga útil, obtuve el mismo error 404. Aunque utilicé el código cUrl generado por Postman, que por lo tanto debería ser idéntico a la solicitud de Postman, hubo una diferencia en la forma en que el servicio web reaccionó a ambas solicitudes. Algunos middleware cliente en Postman pueden haber interceptado y modificado las solicitudes.

TL; DR

Compruebe el servicio web. Puede ser el culpable. Pruebe con otro cliente Http barebones sin navegador como cUrl para ver cómo reacciona el servicio web.