You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Konrad Windszus (JIRA)" <ji...@apache.org> on 2017/06/28 16:23:00 UTC
[jira] [Comment Edited] (JCR-4154) davex upload of binaries broken
[ https://issues.apache.org/jira/browse/JCR-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066770#comment-16066770 ]
Konrad Windszus edited comment on JCR-4154 at 6/28/17 4:22 PM:
---------------------------------------------------------------
Wouldn't it rather make sense to fix the server-side (probably in https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/util/HttpMultipartPost.java). Having a multipart content-disposition header without a filename is totally valid according to https://tools.ietf.org/html/rfc7578#section-4.2.
was (Author: kwin):
Wouldn't it rather make sense to fix the server-side? Having a multipart content-disposition header without a filename is totally valid according to https://tools.ietf.org/html/rfc7578#section-4.2.
> davex upload of binaries broken
> -------------------------------
>
> Key: JCR-4154
> URL: https://issues.apache.org/jira/browse/JCR-4154
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-spi2dav
> Affects Versions: 2.15.4
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Attachments: JCR-4154.diff
>
>
> When using the remoting servlet, upload of binaries seems to be broken (see JCRVLT-186).
> Seems this is caused by the multi part handling on the server assuming the presence of a filename parameter in content-disposition (which was present before we switched to heepclient 4.*)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)