This is now committed, see CMIS-301 and http://svn.apache.org/viewvc?view=revision&revision=1069413
I suggest that the PHP and Python implementations should generate as well this Content-Disposition header to interoperate with OpenCMIS-based servers. Florent PS: the parser code for RFC 822 headers and RFC 2231 non-ASCII parameter encoding is inevitably a bit complex if we want to avoid interop bugs down the line. Code taken from Geronimo. On Wed, Feb 9, 2011 at 1:32 PM, Florian Müller <[email protected]> wrote: > Generating the header shouldn't be that difficult. We only want the > "filename" subset of Content-Disposition. The disposition parameters are all > optional. So we can skip the others. I don't think we need a library for > that. > > Parsing is more tricky. Since we only want the filename bit and can ignore > all others we might content ourselves with a rather simple parser. The major > difficulty is to track the quotes properly. > > > - Florian > > > On 09/02/2011 11:26, Florent Guillaume wrote: >> >> Hm this implies pulling a lot of MIME-related dependencies to just >> generate / parse this header properly. >> >> javax.mail.internet.ParameterList does the work except that the Sun >> implementation needs a system property for RFC 2231 to be activated, >> doh. >> >> geronimo-javamail_1.4_spec has an implementation as well, but I'm >> afraid of classloader clashes. >> >> If we want to go the Content-Disposition route, then I think we'll >> have to copy what's needed from Geronimo. >> >> Florent >> >> On Wed, Feb 9, 2011 at 11:30 AM, Florent Guillaume<[email protected]> wrote: >>> >>> Good points. >>> Content-Disposition is good; while it's mostly used for download, it's >>> also used on multipart HTML file uploads, so there's precedent. >>> I'll try to find a suitable RFC 2231 implementation. >>> >>> Florent >>> >>> On Tue, Feb 8, 2011 at 9:37 PM, Florian Müller >>> <[email protected]> wrote: >>>> >>>> Hi Florent, >>>> >>>> The updatability of the cmis:contentStreamFileName property is not >>>> defined in the spec and might be read-only. >>>> Updates will fail, I reckon, for many repositories. >>>> >>>> How about setting the Content-Disposition header instead? >>>> >>>> For example: >>>> Content-Disposition: attachment; filename="document.pdf" >>>> >>>> >>>> - Florian >>>> >>>> >>>> On 08/02/2011 16:03, Florent Guillaume wrote: >>>>> >>>>> Hi, >>>>> >>>>> CMIS 1.0 defers to AtomPub for the implementation of the >>>>> setContentStream operation (just do a PUT on the edit-media link). But >>>>> this does not allow setting the filename directly, which makes >>>>> higher-level abstraction layers like our Document#setContentStream >>>>> Java API not symmetrical and surprising to users. >>>>> >>>>> I see several things we could do: >>>>> 1. pass the filename in an additional Slug: header as suggested by >>>>> AtomPub (but only suggested for POSTs to collections), >>>>> 2. pass the filename as an additional&filename=foo.png in the URL (or >>>>> x-opencmis-filename=...), >>>>> 3. in the client library do an additional call to edit the >>>>> cmis:contentStreamFileName (suggested by AtomPub 9.6.1 in the >>>>> examples, "The client can edit the metadata for the picture..."). >>>>> >>>>> For the first two this would have to be done both on the client side >>>>> and on the server side so that we interoperate at least with >>>>> ourselves. The question is, which of those would likely be adopted by >>>>> others as "extensions", and maybe mentioned in CMIS 1.1 or 2.0. >>>>> The last one involves an additional round trip to the server. >>>>> >>>>> Thoughts? I'm inclined to implement 3. for now, in >>>>> o.a.c.o.client.bindings.spi.atompub.ObjectServiceImpl.setContentStream. >>>>> >>>>> Florent >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Florent Guillaume, Director of R&D, Nuxeo >>> Open Source, Java EE based, Enterprise Content Management (ECM) >>> http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 >>> >> >> >> > > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
