Posting a multipart request with Content-Disposition: attachment, as specified by e.g. Section 6.5.3 of the SWORD 2.0 Profile:
The client MUST supply a Content-Disposition header of type attachment on the Entry Part with a name parameter set to atom [SWORD004]
The client MUST supply a Content-Disposition header of type attachment on the Media Part with a name parameter set to payload and a filename parameter [SWORD004]
results in an exception with the message Attempting to store and check deposit which has no input stream.
The underlying cause appears to be Commons-Fileupload bug FILEUPLOAD-239, closed as invalid based on (IMO) a misreading of RFC 1867, which accepts only Content-Disposition: form-data. I was able to work around this by patching SwordAPIEndpoint.getPartsFromRequest() with a more liberal getFieldName() implementation.
// Create a new file upload handler
ServletFileUpload upload = new ServletFileUpload(factory) {
// Work around WONTFIX https://issues.apache.org/jira/browse/FILEUPLOAD-239
@Override
protected String getFieldName(FileItemHeaders headers) {
String contentDisposition = headers.getHeader(CONTENT_DISPOSITION);
if (contentDisposition != null) {
ParameterParser parser = new ParameterParser();
parser.setLowerCaseNames(true);
Map params = parser.parse(contentDisposition, ';');
String fieldName = (String) params.get("name");
if (fieldName != null) {
return fieldName.trim();
}
}
return null;
}
};
Posting a multipart request with
Content-Disposition: attachment
, as specified by e.g. Section 6.5.3 of the SWORD 2.0 Profile:results in an exception with the message
Attempting to store and check deposit which has no input stream
.The underlying cause appears to be Commons-Fileupload bug FILEUPLOAD-239, closed as invalid based on (IMO) a misreading of RFC 1867, which accepts only
Content-Disposition: form-data
. I was able to work around this by patchingSwordAPIEndpoint.getPartsFromRequest()
with a more liberalgetFieldName()
implementation.