当给定 jsession id 时，Java Applet 似乎使用旧的响应对象 [英] Java Applet seems to use old response object when given jsession id
问题描述
我的 jsf 页面中有一个文件上传小程序.这个小程序需要一个地址，它可以发送它的 POST 请求.(我无法编辑此帖子请求以添加更多字段或其他内容).我的 servlet 的 post 方法然后存储文件.托管 bean 无法完成这项工作，因为 servlet 必须使用 @MultiPartConfig 进行注释，而我无法将此注释添加到 jsf 托管 bean.为了强制上传小程序使用相同的会话，我根据这个 主题.现在，每当我在会话期间尝试上传多个文件时，小程序都会停止并显示错误消息在响应正文中找不到正则表达式字符串^SUCCESS$"，这是因为小程序期望在 servlet 响应中出现此字符串以便知道上传成功.
I have a file upload applet in my jsf page. This applet expects an adress where it can send it's POST request. (I can't edit this post request to add more fields or something). The post method of my servlet then stores the file. This job can't be done by a managed bean because the servlet has to be annotated with @MultiPartConfig and I can't add this annotation to the jsf managed bean. In order to force the upload applet to use the same session I added an URL attribute named jsessionId to the post request according to this topic. Now whenever I try to upload more than one file during a session the applet stops with the error message "The regexp string "^SUCCESS$" was not found in the response body" this is because the applet expects this string in the servlets response in order to know that the upload was successfull.
当我查看小程序的调试代码时，响应包含很多 html 代码，但没有这个成功字符串，尽管我将它添加到我的 Servlet 代码中.这是我的 servlet 的代码:
When I view the debug code of the applet the response contains a lot of html code but not this success string altough I add it in my Servlet code. Here's the code of my servlet :
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.reset();
if (!userBean.getUploadedDatasets().isEmpty()) {
String datasetID = userBean.getUploadedDatasets().getLast().replaceAll("/", "%2F");
response.sendRedirect(response.encodeRedirectURL("http://____________/faces/details.xhtml?id="+datasetID));
}
}
/**
* Handles the HTTP
* <code>POST</code> method.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response){
PrintWriter out = null;
try {
Part filePart = request.getPart("item");
InputStream filecontent = filePart.getInputStream();
String datasetID = repBean.persistDataset(filecontent, uploadBean.getFolder());
userBean.getUploadedDatasets().add(datasetID);
out = response.getWriter();
out.println("SUCCESS");
} catch (ServletException ex) {
Logger.getLogger(RequestHandler.class.getName()).log(Level.SEVERE, null, ex);
} catch (IOException ex) {
Logger.getLogger(RequestHandler.class.getName()).log(Level.SEVERE, null, ex);
}finally{
out.close();
}
}
小程序使用doGet方法作为afterUploadURL(所以这是上传文件后跳转到的url)
the doGet method is used as afterUploadURL by the applet (so that's the url to which is jumped after a file is uploaded)
小程序代码是:
<APPLET
CODE="wjhk.jupload2.JUploadApplet"
NAME="JUpload"
ARCHIVE="wjhk.jupload.jar"
WIDTH="640"
HEIGHT="300"
MAYSCRIPT="true"
ALT="The java pugin must be installed.">
<param name="postURL" value="http://________________/request;jsessionid=#{session.id}" />
<!-- Optionnal, see code comments -->
<param name="showLogWindow" value="false" />
<param name="debugLevel" value="99" />
<param name="httpUploadParameterName" value="item" />
<param name="nbFilesPerRequest" value="1" />
<param name="httpUploadParameterType" value="oneFile" />
<param name="afterUploadURL" value="http://________________/request" />
</APPLET>
在尝试上传第二个文件后，旧"(这就是我的想法，但我对 servlet 了解不够)响应如下所示:http://pastebin.ca/2300999(字符太多，所以我不得不在那里上传)
and after trying to upload a second file, the "old" (that's what I think but I don't know enough about servlets) response looks like this : http://pastebin.ca/2300999 (too many characters so I had to upload it there)
推荐答案
您的问题是由于 servlet 正在发送 GET(以及隐式也是 HEAD)请求的重定向.日志的以下部分包含相关信息:
Your problem is caused because the servlet is sending a redirect on GET (and implicitly also HEAD) request. The following part of the log contains relevant information:
00064 13:44:42.482 HttpProtocolFinderThread [DEBUG] Getting serverProtocol from HEAD request
00065 13:44:42.485 HttpProtocolFinderThread [DEBUG] Checking protocol with URL: http://___________________:8080/application1/request;jsessionid=47440f88e532021656b3724eea33
00066 13:44:42.501 HttpProtocolFinderThread [DEBUG] [initByteArrayEncoder] proxy=DIRECT, proxy.type=DIRECT, useProxy=false, url.host=___________________, url.port=8080
00067 13:44:42.501 HttpProtocolFinderThread [DEBUG] [onAppendHeader] Start
00068 13:44:42.502 HttpProtocolFinderThread [DEBUG] [onAppendHeader] Header appended; Cookie: __utma=132868616.170774110.1354796930.1356109339.1356547898.3; __utmz=132868616.1356547898.3.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
00069 13:44:42.509 HttpProtocolFinderThread [DEBUG] [onAppendHeader] Header appended; User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0
00070 13:44:42.510 HttpProtocolFinderThread [DEBUG] [onAppendHeader] End
00071 13:44:42.510 HttpProtocolFinderThread [DEBUG] [HTTPConnectionHelper append]
00072 13:44:42.511 HttpProtocolFinderThread [DEBUG] Before sendRequest()
00073 13:44:42.511 HttpProtocolFinderThread [DEBUG] Using non SSL socket, direct connection
00074 13:44:42.538 HttpProtocolFinderThread [DEBUG] After sendRequest()
00075 13:44:42.538 HttpProtocolFinderThread [DEBUG] -------------------------------------------------------------------------
00076 13:44:42.538 HttpProtocolFinderThread [DEBUG] ----------------- HEAD message sent (start) --------------------------
00077 13:44:42.539 HttpProtocolFinderThread [DEBUG] -------------------------------------------------------------------------
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] HEAD /application1/request;jsessionid=47440f88e532021656b3724eea33 HTTP/1.1
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Host: ___________________:8080
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Accept: */*
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Accept-Encoding: identity
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Connection: close
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] Cookie: __utma=132868616.170774110.1354796930.1356109339.1356547898.3; __utmz=132868616.1356547898.3.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG] User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0
00078 13:44:42.539 HttpProtocolFinderThread [DEBUG]
00079 13:44:42.539 HttpProtocolFinderThread [DEBUG] -------------------------------------------------------------------------
00080 13:44:42.540 HttpProtocolFinderThread [DEBUG] ----------------- HEAD message sent (end) -----------------------------
00081 13:44:42.540 HttpProtocolFinderThread [DEBUG] -------------------------------------------------------------------------
00082 13:44:42.548 HttpProtocolFinderThread [DEBUG] -------- Response Headers Start --------
00083 13:44:42.556 HttpProtocolFinderThread [DEBUG] HTTP/1.1 302 Moved Temporarily
00084 13:44:42.558 HttpProtocolFinderThread [DEBUG] Location: http://___________________:8080/application1/faces/details.xhtml;jsessionid=47440f88e532021656b3724eea33?id=%2F37ded64f-f2c9-4b90-99ea-79c34eb140e5
00085 13:44:42.559 HttpProtocolFinderThread [DEBUG] Content-Type: text/html;charset=ISO-8859-1
00086 13:44:42.566 HttpProtocolFinderThread [DEBUG] Content-Language: de-DE
00087 13:44:42.578 HttpProtocolFinderThread [DEBUG] Content-Length: 306
00088 13:44:42.578 HttpProtocolFinderThread [DEBUG] Date: Thu, 10 Jan 2013 12:44:42 GMT
00089 13:44:42.579 HttpProtocolFinderThread [DEBUG] Connection: close
00090 13:44:42.579 HttpProtocolFinderThread [DEBUG]
00091 13:44:42.580 HttpProtocolFinderThread [DEBUG] --------- Response Headers End ---------
00092 13:44:42.580 HttpProtocolFinderThread [DEBUG] This is a HEAD request: we don't care about the bytearrayResponseBody
00093 13:44:42.584 HttpProtocolFinderThread [DEBUG] HEAD status: 302
00094 13:44:42.585 HttpProtocolFinderThread [DEBUG] HEAD protocol: HTTP/1.1
00095 13:44:42.586 HttpProtocolFinderThread [DEBUG] Location read: http://___________________:8080/application1/faces/details.xhtml;jsessionid=47440f88e532021656b3724eea33?id=%2F37ded64f-f2c9-4b90-99ea-79c34eb140e5
00096 13:44:42.594 HttpProtocolFinderThread [INFO] postURL switched from http://___________________:8080/application1/request;jsessionid=47440f88e532021656b3724eea33 to http://___________________:8080/application1/faces/details.xhtml;jsessionid=47440f88e532021656b3724eea33?id=%2F37ded64f-f2c9-4b90-99ea-79c34eb140e5
小程序基本上是通过 HEAD 请求测试 postURL 的可用性，一旦确定它已被重定向，它就会使用重定向的 URL 作为新的 postURL(根据复制粘贴日志的最后一行).但是，重定向的 URL 指向一个返回一大堆 HTML 的 JSF 页面.
The applet is basically testing the availability of postURL by a HEAD request and once determined that it's been redirected, it's using the redirected URL as new postURL (as per the last line of the copypasted log). However, the redirected URL is pointing to a JSF page which returns a whole bunch of HTML.
您需要修复您的 doGet() 以使其不执行重定向，或者添加一个 doHead() 实际上什么都不返回.由于 HEAD 根据 HTTP 规范基本上是没有响应主体的 GET，默认 doHead() 实现委托给 doGet() 并丢弃响应主体.覆盖 doHead() 应该可以防止它委托给 doGet().
You need to fix your doGet() that it doesn't perform a redirect, or to add a doHead() which returns effectively nothing. As a HEAD is per the HTTP specification basically a GET without a response body, the default doHead() implementation delegates to the doGet() and discards the response body. Overriding the doHead() should prevent it from delegating to doGet().
这篇关于当给定 jsession id 时，Java Applet 似乎使用旧的响应对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
