L'URL è accessibile con il browser, ma ancora FileNotFoundException con URLConnection

Question

Uso un HttpURLConnection per connettersi a un sito Web e ricevere un ResponseCode = 404 (HTTP_NOT_FOUND). Tuttavia non ho alcun problema ad aprire il sito web nel mio browser (IE).

Perché la differenza e cosa posso fare a riguardo?

saluti, Pavan

Questo è il mio programma

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()); 
     } 
    } 

} 

Stack Trace

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

se l'URL http://localhost:8080/ si può accedere anche nel browser web, il codice dovrebbe funzionare bene. Corro il programma nella mia macchina, funziona bene. Quindi è necessario verificare se il servizio webserver è ok.

Answer 2

Si sta ricevendo errore 404 che indica che la risposta per la richiesta non è stata trovata. Per prima cosa devi assicurarti che ci sia un server che serve a http://localhost:8080/ e deve restituire del contenuto con il codice 200. In caso contrario, non c'è nulla che possa aiutarti.

Il modo più semplice per verificare se nell'URL ci sia qualcosa è di incollare l'url sulla barra degli indirizzi del browser Web e fare clic su Vai. Tuttavia, questo non garantisce che il codice Java sarà in grado di accedervi. Ad esempio, se il server è progettato per la risposta 404 se non riesce a trovare l'intestazione del browser Web User-Agent.

Poiché il server restituisce un codice di stato, 200 o 404, significa che non si tratta di un problema del firewall.

In base alla tua ultima edizione della domanda, è possibile visualizzarlo con il browser Web ma non è possibile scaricarlo con il proprio codice java e l'intestazione sembra essere impostata correttamente. Ci sono solo due problemi che posso vedere:

1. non si deve impostare connection.setDoOutput(true); su true. Ciò imporrà la connessione per eseguire POST HTTP anziché GET e il server potrebbe non supportare POST.

2. Il server potrebbe restituire sempre 404 anche se avrebbe dovuto essere 200. Poiché il browser Web non si preoccupa dello stato dell'errore e tenta di eseguire il rendering di tutto il contenuto, sembra che funzioni dal browser web. Se è così, si dovrebbe risolvere il server per réponse correttamente prima, altrimenti provare a ottenere flusso di errore invece HttpURLConnection#getErrorStream()

Answer 3

So che questo è molto tardi nel gioco, ma mi è stato solo di recente avendo lo stesso problema e nessuno dei le soluzioni qui hanno funzionato per me. Nel mio caso, in realtà avevo un altro processo in esecuzione sulla stessa porta che stava rubando le richieste dall'app java. Utilizzando la risposta di yair here è possibile verificare un processo in esecuzione sulla stessa porta in questo modo: Nel prompt dei comandi, fare netstat -nao | find "8080" su Windows o netstat -nap | grep 8080 su Linux. Dovrebbe mostrare una riga con LISTENING e 127.0.0.1:8080 e il prossimo sarebbe l'ID del processo. Basta interrompere il processo e dovresti essere pronto.

Answer 4

Ho avuto un problema simile. Per me ha aiutato a ispezionare i pacchetti usando RawCap. RawCap è uno dei pochi sniffer di pacchetti di Windows che consente di sniffare localhost.

Nei miei casi il server restituiva un 404 a causa di un problema di autenticazione.

Answer 5

ho avuto il problema troppo. Nel mio caso ho avuto un carattere unicode invisibile nella stringa url. Quindi la connessione non potrebbe aprirlo (FileNotFound indica ciò). L'ho rimosso e ha funzionato.

Answer 6

Avevo uno scenario simile in cui il servizio Web elaborava le richieste POST dal browser (nel mio caso Postman, un'API che testava l'estensione di Chrome) correttamente, ma HttpURLConnection continuava a fallire con un 404 per grandi payload. Ho erroneamente presupposto che il problema deve essere nel mio codice client HttpURLConnection.

Quando poi ho cercato di replicare la richiesta di riccioli con un grande carico utile, ho ottenuto lo stesso errore 404. Anche se ho usato il codice cUrl generato da postino, che quindi dovrebbe essere identica alla richiesta di postino, c'era una differenza nel modo in cui il servizio web ha reagito a entrambe le richieste. Alcuni middleware client su Postman potrebbero aver intercettato e modificato le richieste.

TL; DR

Controllare il servizio web. Potrebbe essere il colpevole. Prova un altro client Http barebone non-browser come cUrl per vedere come reagisce il servizio web.