繁体   English   中英

使用 HttpUrlConnection 访问 Tomcat 时为 404,浏览器为 200

[英]404 when accessing Tomcat with HttpUrlConnection, 200 from browser

我收到了最奇怪的 Tomcat 错误。 我有一个 Web 应用程序在我的本地主机上使用 tomcat 运行在端口 8080 上,一切似乎都运行良好,没有错误等。但是,当我尝试使用 HttpURLConnection 类从另一个应用程序访问此 Web 应用程序时,出现 404 错误。 奇怪的是,当我在浏览器中放置相同的 URL 时,它返回一个 200 代码并有一个有效的响应。

我已经从这些帖子中尝试/检查了以下内容: post1post2

  1. 设置User AgentAccept标头。
  2. 我已经检查了响应正文(使用HttpURLConnection.getInputStream()以及HttpURLConnection.getErrorStream() ,在 404 是不正确的返回代码的情况下)并且确实得到了一个页面未找到响应。
  3. 我尝试将connection.setDoOutput()设置为truefalse但没有帮助。
  4. 尝试将localhost更改为127.0.0.1

更多信息,我查看了Tomcat访问日志,似乎请求从未到达服务器(意味着请求从未被记录)。 但是,当我将 url 放入浏览器(并获得有效响应)时,请求确实显示在日志中。

还有一件事,我正在使用 eclipse 运行 tomcat。 是的,该应用程序正在服务器上部署。

另外,我发现,似乎有完全相同的问题有人在这里,但没有办法解决,所以我把这个问题给做的伟大的社会!

编辑:来自调用应用程序的代码:

出于隐私原因,我隐藏了网址

 public static void main(String[] args) {
    final String url = ""; 
    try {
        URL obj = new URL(url);
        HttpURLConnection con = (HttpURLConnection) obj.openConnection();
        con.setDoOutput(false);
        System.out.println(con.getResponseCode());
        System.out.println(getStringFromInputStream(con.getInputStream()));
    } catch (Exception e) {
        e.printStackTrace();
    }
    System.out.println("DONE");
}

是的,这确实适用于其他主机,例如 google。 我从http://www.google.com得到的回复是这样的:

200
<!doctype html><html....>*bunch of html*</html>
DONE

回复http://localhost:8080/...

    404
    java.io.FileNotFoundException: *url*
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at     sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
    at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1674)
    at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1672)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1670)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1243)
    at Get.main(Get.java:32)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.io.FileNotFoundException: *url*
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1623)
    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
    at Get.main(Get.java:31)
    ... 5 more
DONE

因此,通过关闭从 Eclipse 运行的 Tomcat 并重试应用程序和浏览器请求,我们发现某些进程正在窃取您的请求。

您可以通过运行netstat -nao | find "8080"找到小偷netstat -nao | find "8080" 在 Windows 或netstat -nap | grep 8080netstat -nao | find "8080" netstat -nap | grep 8080 Linux 上的netstat -nap | grep 8080 它应该显示一行,其中包含LISTENING127.0.0.1:8080 ,接下来是进程 ID。

我遇到了同样的错误,并得到了原因,jdbc configure 中的用户名被绑定到使用网络地址访问mysql,即:192.168。 . 而不是本地主机,我更改了用户名并成功了。

我有同样的问题,当我从浏览器运行https://127.0.0.1时它工作正常,但 https://localhost 或 http://localhost:8080 在浏览器和 Eclispe 中不起作用。 我刚刚在 Windows 上尝试过 netstat -nao|find "8080",我得到以下结果


TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING       30748
  TCP    25.208.159.83:64002    165.225.39.27:8080     TIME_WAIT       0
  TCP    25.208.159.83:64037    165.225.39.27:8080     TIME_WAIT       0
  TCP    25.208.159.83:64117    165.225.39.27:8080     TIME_WAIT       0
  TCP    25.208.159.83:64197    185.46.212.88:8080     SYN_SENT        11044
  TCP    25.208.159.83:64200    165.225.39.27:8080     TIME_WAIT       0
  TCP    [::]:8080              [::]:0                 LISTENING       30748

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM