{"action":"created","issue":{"url":"https://api.github.com/repos/swordapp/JavaServer2.0/issues/11","repository_url":"https://api.github.com/repos/swordapp/JavaServer2.0","labels_url":"https://api.github.com/repos/swordapp/JavaServer2.0/issues/11/labels{/name}","comments_url":"https://api.github.com/repos/swordapp/JavaServer2.0/issues/11/comments","events_url":"https://api.github.com/repos/swordapp/JavaServer2.0/issues/11/events","html_url":"https://github.com/swordapp/JavaServer2.0/issues/11","id":162511699,"number":11,"title":"Endpoint can't parse multipart requests with Content-Disposition: attachment","user":{"login":"dmolesUC3","id":10374934,"avatar_url":"https://avatars.githubusercontent.com/u/10374934?v=3","gravatar_id":"","url":"https://api.github.com/users/dmolesUC3","html_url":"https://github.com/dmolesUC3","followers_url":"https://api.github.com/users/dmolesUC3/followers","following_url":"https://api.github.com/users/dmolesUC3/following{/other_user}","gists_url":"https://api.github.com/users/dmolesUC3/gists{/gist_id}","starred_url":"https://api.github.com/users/dmolesUC3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dmolesUC3/subscriptions","organizations_url":"https://api.github.com/users/dmolesUC3/orgs","repos_url":"https://api.github.com/users/dmolesUC3/repos","events_url":"https://api.github.com/users/dmolesUC3/events{/privacy}","received_events_url":"https://api.github.com/users/dmolesUC3/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-06-27T18:02:12Z","updated_at":"2016-06-27T18:41:19Z","closed_at":null,"body":"Posting a multipart request with `Content-Disposition: attachment`, as specified by e.g. [Section 6.5.3](http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#protocoloperations_editingcontent_multipart) of the SWORD 2.0 Profile:\r\n\r\n> - The client MUST supply a Content-Disposition header of type attachment on the Entry Part with a name parameter set to atom [SWORD004]\r\n> - 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] \r\n\r\nresults in an exception with the message `Attempting to store and check deposit which has no input stream`.\r\n\r\nThe underlying cause appears to be Commons-Fileupload bug [FILEUPLOAD-239](https://issues.apache.org/jira/browse/FILEUPLOAD-239), closed as invalid based on (IMO) a misreading of [RFC 1867](http://www.ietf.org/rfc/rfc1867.txt), which accepts only `Content-Disposition: form-data`. I was able to work around this by patching [`SwordAPIEndpoint.getPartsFromRequest()`](https://github.com/swordapp/JavaServer2.0/blob/06d04f5e959465ae577f40a891ff6c930df2cd5e/src/main/java/org/swordapp/server/SwordAPIEndpoint.java#L465) with a more liberal `getFieldName()` implementation.\r\n\r\n```java\r\n// Create a new file upload handler\r\nServletFileUpload upload = new ServletFileUpload(factory) {\r\n\t// Work around WONTFIX https://issues.apache.org/jira/browse/FILEUPLOAD-239\r\n\t@Override\r\n\tprotected String getFieldName(FileItemHeaders headers) {\r\n\t\tString contentDisposition = headers.getHeader(CONTENT_DISPOSITION);\r\n\t\tif (contentDisposition != null) {\r\n\t\t\tParameterParser parser = new ParameterParser();\r\n\t\t\tparser.setLowerCaseNames(true);\r\n\t\t\tMap params = parser.parse(contentDisposition, ';');\r\n\t\t\tString fieldName = (String) params.get(\"name\");\r\n\t\t\tif (fieldName != null) {\r\n\t\t\t\treturn fieldName.trim();\r\n\t\t\t}\r\n\t\t}\r\n\t\treturn null;\r\n\t}\r\n};\r\n```"},"comment":{"url":"https://api.github.com/repos/swordapp/JavaServer2.0/issues/comments/228836630","html_url":"https://github.com/swordapp/JavaServer2.0/issues/11#issuecomment-228836630","issue_url":"https://api.github.com/repos/swordapp/JavaServer2.0/issues/11","id":228836630,"user":{"login":"dmolesUC3","id":10374934,"avatar_url":"https://avatars.githubusercontent.com/u/10374934?v=3","gravatar_id":"","url":"https://api.github.com/users/dmolesUC3","html_url":"https://github.com/dmolesUC3","followers_url":"https://api.github.com/users/dmolesUC3/followers","following_url":"https://api.github.com/users/dmolesUC3/following{/other_user}","gists_url":"https://api.github.com/users/dmolesUC3/gists{/gist_id}","starred_url":"https://api.github.com/users/dmolesUC3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dmolesUC3/subscriptions","organizations_url":"https://api.github.com/users/dmolesUC3/orgs","repos_url":"https://api.github.com/users/dmolesUC3/repos","events_url":"https://api.github.com/users/dmolesUC3/events{/privacy}","received_events_url":"https://api.github.com/users/dmolesUC3/received_events","type":"User","site_admin":false},"created_at":"2016-06-27T18:41:19Z","updated_at":"2016-06-27T18:41:19Z","body":"It looks like Apache broke this deliberately in [March 2013](http://svn.apache.org/viewvc/commons/proper/fileupload/tags/FILEUPLOAD_1_3_2/src/main/java/org/apache/commons/fileupload/FileUploadBase.java?r1=1457287&r2=1457288&).\r\n\r\n(I thought there might be something weirder going on, but I wasn't using the SVN browser correctly.)"}}
{"actor":{"display_login":"dmolesUC3"}}