[
https://issues.apache.org/jira/browse/JCR-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16067611#comment-16067611
]
Tobias Bocanegra commented on JCR-4154:
---------------------------------------
bq. We may want to do both. Fixing it on the server side might be a bit harder
though, so let's make the client compatible with existing servers first...
(davex remoting is really a black box anyway – I'm not aware of any code other
than Jackrabbit's own interoperating with it)
I agree. since no issue was reported ever against the server side, I don't
think that it is problematic. but ensuring that the client doesn't show a
regression is more important. for example fiilevault relies on davex (see
JCRVLT-186).
> 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.0, 2.14.0
> 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)
