[英]Apache HttpClient POST Upload File won't work with MultipartEntityBuilder upload
I have an HTML form that has a File Upload in it.我有一个 HTML 表单,其中包含文件上传。 I am trying to upload a Word doc through the form using
MultipartEntityBuilder
, but it is just not working.我正在尝试使用
MultipartEntityBuilder
通过表单上传 Word 文档,但它不起作用。
The form has several text inputs and 2 File Upload lines in it.表单中有几个文本输入和 2 个文件上传行。 If I use the
BasicNameValuePair
approach and just set those fields as empty Strings, the text fields are submitted correctly.如果我使用
BasicNameValuePair
方法并将这些字段设置为空字符串,则文本字段将正确提交。 Since I need to upload the files, I changed to MultipartEntityBuilder
and can't even get the basic test working again.由于我需要上传文件,我改为
MultipartEntityBuilder
并且甚至无法再次进行基本测试。
The Working Code工作守则
HttpClient client = HttpClientBuilder.create().build();
String uploadUrl = "http://somepage.com/upload";
HttpPost httppost = new HttpPost(uploadUrl);
httppost.setHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8");
httppost.setHeader("Content-Type", "multipart/form-data");
httppost.setHeader("Accept-Encoding", "gzip, deflate");
List<NameValuePair> formparams = new ArrayList<NameValuePair>();
formparams.add(new BasicNameValuePair("testField1", "Value1"));
formparams.add(new BasicNameValuePair("testField2", "Value2"));
formparams.add(new BasicNameValuePair("fileField1", ""));
formparams.add(new BasicNameValuePair("fileField2", ""));
httppost.setEntity(new UrlEncodedFormEntity(formparams, Consts.UTF_8));
HttpResponse response = client.execute(httppost, httpContext);
Trying MultipartEntityBuilder尝试 MultipartEntityBuilder
// Everything up to and including the Headers remain the same
MultipartEntityBuilder builder = MultipartEntityBuilder.create();
builder.setMode(HttpMultipartMode.BROWSER_COMPATIBLE);
StringBody sb = new StringBody("Value1", ContentType.TEXT_PLAIN);
builder.addPart("textField1", sb);
sb = new StringBody("Value2", ContentType.TEXT_PLAIN);
builder.addPart("textField2", sb);
FileBody fb = new FileBody(new File("path to file"), ContentType.DEFAULT_BINARY);
builder.addPart("fileField1", fb);
fb = new FileBody(new Field("path to file2"), ContentType.DEFAULT_BINARY);
builder.addPart("fileField2", fb);
httppost.setEntity(builder.build());
HttpResponse response = client.execute(httppost, httpContext);
The form is hosted by Oracle and get back the error:该表单由 Oracle 托管并返回错误:
An unexpected error occurred: ORA-06501: PL/SQL: program error
发生意外错误:ORA-06501:PL/SQL:程序错误
I have also tried these other approaches:我也尝试过这些其他方法:
builder.addTextBody("textField1", "Value1");
builder.addTextBody("textField2", "Value2");
File file1 = new File("path to file1");
builder.addBinaryBody("fileField1", file1, ContentType.DEFAULT_BINARY, file1.getName());
File file2 = new File("path to file2");
builder.addBinaryBody("fileField2", file2, ContentType.DEFAULT_BINARY, file2.getName());
As well as trying to mimic my first test by putting everything in the builder.addTextBody()
like my original working test, but still get the same result.以及尝试通过将所有内容放入
builder.addTextBody()
来模拟我的第一个测试,就像我原来的工作测试一样,但仍然得到相同的结果。
Logging日志记录
As per @oleg request, I have posted the wire log from this call:根据@oleg 请求,我已经发布了这次通话的线路日志:
DEBUG [org.apache.http.client.protocol.RequestAddCookies] CookieSpec selected: default
DEBUG [org.apache.http.client.protocol.RequestAddCookies] Cookie [version: 0][name: SSO_TIMEOUT_ID][value: v1.0~83BA4EF3DA76C07B55F93B5C5D65F90947314693035F046BFCC21BCD37F8B95284E732E711971532B182F90AE461E320FCCC74452BAF4A16FB6E5EFA5F86985B26C95D30001D9ACC3BE8E9D2786B1CD38A79788FC7623FCE06C84266C234638182D44786E4971B53EBFC25FD3B7A565F][domain: isomething.com][path: /][expiry: null] match [wwwdev.isomething.com:80/portal/pls/cust_portal/!CUST_PORTAL.wwa_app_module.accept]
DEBUG [org.apache.http.client.protocol.RequestAddCookies] Cookie [version: 0][name: cust_portal][value: 9.0.3+en-us+us+AMERICA+12955AE0CEA20F3CE050558C15F00BD2+84676D40A18761D45DEBA039A78FF868CA9B49F2DEA2D283DE61561CE0F547D3A27C643219F1E6C867CF150CDEA69AE9844407F570B4BBD967491098CECEEA836861C9FF1F06AF7929814DF3C55426F1C2E73C91B219801B][domain: wwwdev.isomething.com][path: /][expiry: null] match [wwwdev.isomething.com:80/portal/pls/cust_portal/!CUST_PORTAL.wwa_app_module.accept]
DEBUG [org.apache.http.client.protocol.RequestAuthCache] Auth cache not set in the context
DEBUG [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection request: [route: {}->http://wwwdev.isomething.com:80][total kept alive: 0; route allocated: 0 of 2; total allocated: 0 of 20]
DEBUG [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection leased: [id: 4][route: {}->http://wwwdev.isomething.com:80][total kept alive: 0; route allocated: 1 of 2; total allocated: 1 of 20]
DEBUG [org.apache.http.impl.execchain.MainClientExec] Opening connection {}->http://wwwdev.isomething.com:80
DEBUG [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] Connecting to wwwdev.isomething.com/141.146.161.39:80
DEBUG [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] Connection established 10.0.0.2:49827<->141.146.161.39:80
DEBUG [org.apache.http.impl.execchain.MainClientExec] Executing request POST /portal/pls/cust_portal/!CUST_PORTAL.wwa_app_module.accept HTTP/1.1
DEBUG [org.apache.http.impl.execchain.MainClientExec] Target auth state: UNCHALLENGED
DEBUG [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
DEBUG [org.apache.http.headers] http-outgoing-4 >> POST /portal/pls/cust_portal/!CUST_PORTAL.wwa_app_module.accept HTTP/1.1
DEBUG [org.apache.http.headers] http-outgoing-4 >> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
DEBUG [org.apache.http.headers] http-outgoing-4 >> Origin: http://wwwdev.isomething.com
DEBUG [org.apache.http.headers] http-outgoing-4 >> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.104 Safari/537.36
DEBUG [org.apache.http.headers] http-outgoing-4 >> Referer: http://wwwdev.isomething.com/portal/page/cust_portal/SOM_PGR/ReportManager2/ReportManager/SOM_Reports_MTC/SOM_FILE_CLERK_ADD_REPORT?np_report_number=MTC01234567&np_project_number=3141307&np_country=US&np_customer_number=110960&np_module=URM&np_customer_name=MY TEST CENTRAL TEST ACCOUNT
DEBUG [org.apache.http.headers] http-outgoing-4 >> Accept-Encoding: gzip, deflate
DEBUG [org.apache.http.headers] http-outgoing-4 >> Accept-Language: en-US,en;q=0.8
DEBUG [org.apache.http.headers] http-outgoing-4 >> DNT: 1
DEBUG [org.apache.http.headers] http-outgoing-4 >> Content-Length: 49234
DEBUG [org.apache.http.headers] http-outgoing-4 >> Content-Type: multipart/form-data; boundary=_I6HZ69Fquh0RHe-DNWGs9tfX48pemmkOYs
DEBUG [org.apache.http.headers] http-outgoing-4 >> Host: wwwdev.isomething.com
DEBUG [org.apache.http.headers] http-outgoing-4 >> Connection: Keep-Alive
DEBUG [org.apache.http.headers] http-outgoing-4 >> Cookie: SSO_TIMEOUT_ID=v1.0~83BA4EF3DA76C07B55F93B5C5D65F90947314693035F046BFCC21BCD37F8B95284E732E711971532B182F90AE461E320FCCC74452BAF4A16FB6E5EFA5F86985B26C95D30001D9ACC3BE8E9D2786B1CD38A79788FC7623FCE06C84266C234638182D44786E4971B53EBFC25FD3B7A565F; cust_portal=9.0.3+en-us+us+AMERICA+12955AE0CEA20F3CE050558C15F00BD2+84676D40A18761D45DEBA039A78FF868CA9B49F2DEA2D283DE61561CE0F547D3A27C643219F1E6C867CF150CDEA69AE9844407F570B4BBD967491098CECEEA836861C9FF1F06AF7929814DF3C55426F1C2E73C91B219801B
DEBUG [org.apache.http.headers] http-outgoing-4 << HTTP/1.1 200 OK
DEBUG [org.apache.http.headers] http-outgoing-4 << Cache-Control: max-age=0
DEBUG [org.apache.http.headers] http-outgoing-4 << Content-Type: text/html; charset=UTF-8
DEBUG [org.apache.http.headers] http-outgoing-4 << Set-Cookie: SSO_TIMEOUT_ID=v1.0~83BA4EF3DA76C07B68FCC2530F599A0EC0C64F824C7AE3F72C95A8D07625F4915248DB9B7D40E28DF645BB373ADAE5E39B2A539F98F48507192E9993DAFEDE4D30331E7912A944E0A9C203BD851C0C0D7DCBC672186F9DF652220BC26B85C327A81DE6656E5D73550FCD2EA1BA53552F; domain=.isomething.com; path=/
DEBUG [org.apache.http.headers] http-outgoing-4 << Connection: Keep-Alive
DEBUG [org.apache.http.headers] http-outgoing-4 << Keep-Alive: timeout=5, max=999
DEBUG [org.apache.http.headers] http-outgoing-4 << Server: Oracle-Application-Server-10g/10.1.2.3.0 Oracle-HTTP-Server OracleAS-Web-Cache-10g/10.1.2.3.2 (N;ecid=100569954162,0)
DEBUG [org.apache.http.headers] http-outgoing-4 << Content-Length: 5134
DEBUG [org.apache.http.headers] http-outgoing-4 << Date: Tue, 31 Mar 2015 13:06:53 GMT
DEBUG [org.apache.http.headers] http-outgoing-4 << Content-Location: /servlet/RepositoryServlet/cust_portal/!CUST_PORTAL.wwa_app_module.accept
DEBUG [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive for 5000 MILLISECONDS
DEBUG [org.apache.http.client.protocol.ResponseProcessCookies] Cookie accepted [SSO_TIMEOUT_ID="v1.0~83BA4EF3DA76C07B68FCC2530F599A0EC0C64F824C7AE3F72C95A8D07625F4915248DB9B7D40E28DF645BB373ADAE5E...", version:0, domain:isomething.com, path:/, expiry:null]
Some time ago I spent lots of time trying to submit multipart form with file.前段时间我花了很多时间尝试提交带有文件的多部分表单。 Finally problem were solved by adding boundary.
最后通过添加边界解决了问题。 As I understood after some debugging server wasn't able to recognize parts without it.
正如我在一些调试服务器没有它的情况下无法识别零件后所了解的那样。
String boundary = "---------------"+UUID.randomUUID().toString();
multipartEntityBuilder.setBoundary(boundary);
...
HttpPost request = new HttpPost(uriBuilder.build());
request.setHeader("Content-Type", ContentType.MULTIPART_FORM_DATA.getMimeType()+";boundary="+boundary);
...
multipartEntityBuilder.addBinaryBody("document[file]", dataBytes, ContentType.APPLICATION_OCTET_STREAM, name);
Try removing this line尝试删除此行
httppost.setHeader("Content-Type", "multipart/form-data");
Updated更新
as expected the application is sending invalid Content-Type header正如预期的那样,应用程序正在发送无效的 Content-Type 标头
[org.apache.http.headers] http-outgoing-5 >> Content-Type: multipart/form-data
Please do not set Content-Type
manually and let HttpClient generate it for you based on properties of the HttpEntity
enclosed in the request请不要手动设置
Content-Type
,让 HttpClient 根据请求中包含的HttpEntity
属性为您生成它
I struggled with this for just... too long.我为此挣扎了……太久了。 For hours!?
用了几个小时!? Anyway, I had this little wrapper class so that I could send in "any multipart form", just I wanted the file (I'm sending it as a raw byte[] instead, in my case I have an upload Controller doing the upload to another controller and there is no need to parse a file in this scenario) to be sent tied to a "file" attribute
无论如何,我有这个小包装类,以便我可以以“任何多部分形式”发送,只是我想要文件(我将它作为原始字节 [] 发送,在我的情况下,我有一个上传控制器进行上传到另一个控制器,并且在这种情况下不需要解析文件)将被发送到“文件”属性
@Getter
public class MultipartMap {
private static final String GOT_NUTHIN_TO_MULTIPART_POST = "Got nuthin to multipart-post!!";
private final byte[] toPost;
public final String DEFAULT_FILENAME = "unknownFile";
private final String filename;
private Map<String, String> textParams = new HashMap<>();
public MultipartMap(byte[] data, String fileName, MultipartTextField... multipartTextField) {
this.toPost = data;
this.filename = StringUtils.hasContents(fileName) ? fileName : DEFAULT_FILENAME;
Arrays.stream(multipartTextField).forEach(param -> textParams.put(param.getFormName(), param.getFormValue()));
}
public void isSane() {
if (toPost == null || toPost.length == 0) {
throw new WrappedHttpClientException(GOT_NUTHIN_TO_MULTIPART_POST);
}
}
}
and then I had a nice wrapped HttpClient the way I liked it performing the post of this multipart setup:然后我有一个很好的包装 HttpClient ,我喜欢它执行这个多部分设置的帖子:
private static final String FILE = "file";
private static final String CONTENT_TYPE = "content-type";
..
multipartMap.isSane();
isMultiPartRequest = true;
final MultipartEntityBuilder multipartBuilderInner = MultipartEntityBuilder.create();
multipartBuilderInner.setMode(HttpMultipartMode.BROWSER_COMPATIBLE);
multipartBuilderInner.addBinaryBody(
FILE,
multipartMap.getToPost(),
ContentType.DEFAULT_BINARY,
multipartMap.getFilename()
);
multipartMap.getTextParams().entrySet().stream().forEach(e -> {
multipartBuilderInner.addTextBody(e.getKey(), e.getValue(), ContentType.TEXT_PLAIN);
});
..
HttpPost request = new HttpPost(url);
request.setEntity(multipartBuilderInner.build());
..
if (isMultiPartRequest && req.getAllHeaders() != null) {
request.removeHeaders(CONTENT_TYPE); // this is IMPORTANT for multipart-requests!!
}
Now, just as ok2c notes above - as long as I didn't make absolutely sure (and you should take better care than this, done proper the removeHeaders should be for anything matching regardless of case and so on) that content-type was NOT SET, I would always get the infamous现在,就像上面的 ok2c 注释一样-只要我没有绝对确定(并且您应该比这更小心,正确完成 removeHeaders 应该用于任何匹配的内容,无论大小写等等)内容类型不是SET,我总是会得到臭名昭著的
"Required request part 'xxx' is not present" “所需的请求部分‘xxx’不存在”
back from my controller.从我的控制器回来。 Then, as soon as I made sure no content-type was setup manually, things just worked perfectly.
然后,一旦我确定没有手动设置内容类型,一切就完美无缺了。 Just for reference, the controller on the other side looks like
仅供参考,另一边的控制器看起来像
@PostMapping(path = "saveDocument", produces = "application/json; charset=utf-8", consumes = "multipart/form-data")
public ResponseEntity<String> saveDocument(@RequestPart(value = "file", required = false) MultipartFile file, @RequestPart(value = "filename", required = false) String filename,..
The required = false is just because I wanted to deal with this 400 response myself rather than having Spring reject the request before I could touch it. required = false 只是因为我想自己处理这个 400 响应,而不是让 Spring 在我触摸它之前拒绝请求。 Well well - thanks ok2c, you got my upvote for sure!
好吧 - 谢谢 ok2c,你肯定得到了我的赞成!
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.