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)