Jetty.project: No response getting from server while uploading file with Jetty 9.x
Hello,
I met a problem with jetty almost like this, i uploaded a file to my server (depends on jetty 9.4.7), when getting the request, if i sent a 413 error, i couldn't get any response at client side. i was confused.
However, i did same thing on jetty 8.1.16, it worked. I got the 413 error page i want as the response just like below:
HTTP ERROR: 413
Problem accessing /upload. Reason:
File: 16 MB. Refused the file.
Powered by Jetty://
with my codes, quite simple:
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.servlet.DefaultServlet;
import org.eclipse.jetty.servlet.ServletContextHandler;
import org.eclipse.jetty.servlet.ServletHolder;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.*;
public class JettyService {
public static void main(String[] args) throws Exception {
Server server = new Server(8090); // http://127.0.0.1:8090/
ServletContextHandler context = new ServletContextHandler(ServletContextHandler.SESSIONS);
context.setResourceBase("webapps");
server.setHandler(context);
context.addServlet(new ServletHolder(new HelloWorld()), "/upload");
context.addServlet(new ServletHolder(new DefaultServlet()), "/");
server.start();
server.join();
}
public static class HelloWorld extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
doPost(req, resp);
}
@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.sendError(413, "File: " + req.getContentLength() / 1024 / 1024 + " MB. Refused the file.");
}
}
}
below is my web page , i'm not sure whether u need or not:
<body>
<form action="/upload" method="post" enctype="multipart/form-data">
<input type="file" name="fileUpload" />
<input type="submit" value="upload" />
</form>
</body>
mangtsang
All 15 comments
I copy/pasted your code and then:
$ wget --verbose http://localhost:8090/upload
--2017-10-03 18:22:51-- http://localhost:8090/upload
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:8090... connected.
HTTP request sent, awaiting response... 413 File: 0 MB. Refused the file.
2017-10-03 18:22:51 ERROR 413: File: 0 MB. Refused the file..
Then I copy/pasted your HTML and after choosing a file and clicking on the "upload" button I get:
HTTP ERROR 413
Problem accessing /upload. Reason:
File: 1 MB. Refused the file.
Powered by Jetty:// 9.4.z-SNAPSHOT
I don't know why it's not working for you, but it's not a Jetty issue.
sbordet
on 3 Oct 2017
have u try uploading a big file?
mangtsang
on 6 Oct 2017
@mangtsang yes, I tried uploading a big file.
If you have a reproducible test case with the exact definition of "big", we'll try it out.
Otherwise it's something else.
sbordet
on 6 Oct 2017
may i take a video show u via mail, maybe there is any diff between our demo projects?
mangtsang
on 7 Oct 2017
@mangtsang the video won't help. Give us a reproducible test that we can try ourselves.
sbordet
on 9 Oct 2017
Hi @sbordet ,
I'm still confused by the problem. Could u help me check once more time?
I built the demo project with intellij idea on macOS as below steps:
- build a empty java project with jdk 1.8_144, and import the whole folder jetty-distribution-9.4.7.v20170914/lib into libraries.
- create a single class JettyService, codes can be found above.
- create a webapps directory and index.html file.
- then to build and run the project.
- open http://127.0.0.1:8090 with firefox(developer edition 57.0b6 (64-bit)), and select jetty zip file(17.9MB) to upload, no getting response. and upload the Intellij idea zip(300MB), failed too.
then i tryied doing same thing on Safari(Version 11.0 (13604.1.38.1.6)), it works, whatever size of file to upload, i can get the 413 error page.
In addition, i built a same project on Windows 7 (32bit). And upload file by different browsers:
1. firefox(56.0)
2. IE(11.0.9600.18792)
3. chrome(61.0.3163.100)
All faild getting the 413 error page.
mangtsang
on 15 Oct 2017
I just tried your instructions above, with Linux and Chrome, and works for me: I can get the 413 page without problems.
sbordet
on 16 Oct 2017
Since you stated you are on Windows, can you confirm your firewall software isn't interacting with your tests in a bad way?
joakime
on 16 Oct 2017
@mangtsang Here's a full project using your code ...
https://github.com/joakime/issue-1864
It works from command line (using curl) and from various browsers, using simple html/form upload.
Works fine on Windows 10, Linux, and OSX.
How does it work for you? (See README.md for advice on building/running/testing)
joakime
on 16 Oct 2017
@joakime i forked your project, then make and compile it. the issue reproduced.
https://github.com/mangtsang/issue-1864/blob/master/3_result.png
there is another two snaps(1_project, 2_upload).
Maybe u can also try a very big file, such as 600MB to upload.
mangtsang
on 18 Oct 2017
quite confused..
mangtsang
on 18 Oct 2017
Results of a 1.4GB Upload
$ curl --verbose --data-binary "@Fedora-Workstation-Live-x86_64-25-1.3.iso" http://localhost:8090/upload
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8090 (#0)
> POST /upload HTTP/1.1
> Host: localhost:8090
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Length: 1440743424
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
< HTTP/1.1 413 File: 1374 MB. Refused the file.
< Date: Wed, 18 Oct 2017 15:04:08 GMT
< Cache-Control: must-revalidate,no-cache,no-store
< Content-Type: text/html;charset=iso-8859-1
< Content-Length: 368
< Connection: close
< Server: Jetty(9.4.7.v20170914)
<
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 413 File: 1374 MB. Refused the file.</title>
</head>
<body><h2>HTTP ERROR 413</h2>
<p>Problem accessing /upload. Reason:
<pre> File: 1374 MB. Refused the file.</pre></p><hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.7.v20170914</a><hr/>
</body>
</html>
* Closing connection 0
Result of same ISO uploaded via form in Chrome 61.0.3163.100 (browser running in Windows 10)..
POST /upload HTTP/1.1
Host: localhost:8090
Connection: keep-alive
Content-Length: 1440743752
Pragma: no-cache
Cache-Control: no-cache
Origin: http://localhost:8090
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryIxU6Iq71FHAwXpt8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
DNT: 1
Referer: http://localhost:8090/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Cookie: JSESSIONID=node010mqps7i3ux8suupnbneoixut0.node0; Idea-ce8185c8=34cc77a4-e263-457e-8fa6-fdbc8feab780; visited=yes
------WebKitFormBoundaryIxU6Iq71FHAwXpt8
Content-Disposition: form-data; name="file"; filename="Fedora-Workstation-Live-x86_64-25-1.3.iso"
Content-Type: application/octet-stream
ER.............................
(snip)
HTTP/1.1 413 File: 1374 MB. Refused the file.
Date: Wed, 18 Oct 2017 15:07:38 GMT
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 368
Connection: close
Server: Jetty(9.4.7.v20170914)
@mangtsang the response is definitely present on the wireshark capture of request/response.
However, the browsers sometimes detects the lack of reading of the request and subsequent close as a reset/abort, and seemingly ignore the response information that was sent. Instead showing you the reset of the request side and not the response information.
If you read the request body content, the error goes away.
See commented code in Issue1864.java
I would classify that as a bug in the browser implementation.
So I filed a bug - https://bugs.chromium.org/p/chromium/issues/detail?id=775972
joakime
on 18 Oct 2017
Chrome/Chromium reports that this behavior is a quirk of the Windows Network stack. (huh?)
See: https://bugs.chromium.org/p/chromium/issues/detail?id=775972
joakime
on 21 Oct 2017
Related issues
knaccc
路
3Comments
caokhang91
路
5Comments
IvoLimmen
路
7Comments
gregw
路
4Comments
Auo
路
4Comments
Most helpful comment
@mangtsang the video won't help. Give us a reproducible test that we can try ourselves.