Accessing Mime Attachments in Web Scripts

[r1ch4rd]

Hi Folks,

How can I access Mime Attachments when running at HTTP POST or PUT operation on a web script which I am writing to provide a RESTful service to my Alfresco repository?

I am writing a Share Dashlet which needs to deliver generated content (not from a file upload form) to the repository, but I can't find a way in the Web Scripts environment to access POSTed content.  Actually, further to that, I'm finding it difficult even to generate the appropriate POST using the "remote" javascript object in Share.  At the moment it looks like I'm going to have to literally mock up a mutlipart formdata POST so that I can access the content via the "formdata" Web Script object.  This is obviously a terrible way to go about this, so I must be missing something …

Any suggestions greatly appreciated.

Regards

Richard

[mikeh]

Sounds like a confusing design - if you're generating the content, why can't you send that in an HTTP POST and write it to a file on the server?

Mike

[r1ch4rd]

Hi Mike,

Well, the content is being generated elsewhere, and being given to the dashlet upon request.  The Dashlet's job is to offer the user the opportunity to store in the repository this externally generated content.  Additionally, this is only the tip of the iceberg; I have general requirements to support a RESTful service on my Alfresco repository which will deposit content via HTTP POST, and will contain important information regarding the deposit in the HTTP headers, and which won't have any form data associated with it.

Either way, I don't see what you mean by sending it by HTTP POST and writing it to a file on the server, sorry.  Do you mean cache the generated content in some holding space, outside of the repository?  That seems like an unnecessary additional step.  The problem I'm having with my web scripts is that I don't see how to handle an HTTP POST which /isn't/ a form upload (which is the only practical example of a POST here: http://wiki.alfresco.com/wiki/Web_Scripts_Examples#File_Upload).

Cheers,

Richard

[mikeh]

Well, the content is being generated elsewhere, and being given to the dashlet upon request.

So you've got some binary data in your hand..?

The pertinent part of the upload script is

upload.properties.content.write(content)‍

Now content could come from anywhere - it so happens that to handle a browser-sourced file upload, you get this from parsing multipart-form data. There's no reason why content couldn't come from HTTP POST variable(s), or another node already in the repo.

Mike

[r1ch4rd]

Hi Mike,

OK, yes, this is where I'd already got up to.  What I'm trying to do is find out how that "content" variable can be populated from a straight mime attachment in the HTTP POST.

What I'm looking for is something like

var content = request.getMimeAttachment()

But of course, there isn't a "request" object in scope, which brings me to the purpose of this post   The content is /not/ already in the repository, it's coming out of the ether, and into the repo via this very raw HTTP POST with a binary mime attachment.

Cheers,

Richard

[mikeh]

Ah right, ok. Your options would seem to be either -as you suspected- hand-build the multipart/form request which the browser would normally do for you (it shouldn't be too tricky), or encode the binary data into a POST variable and access it via args as if it was a browser-submitted form request. There is one final option, which is to write your own format reader for the webscript runtime. You could use org.alfresco.web.scripts.servlet.FormDataReader as a starting point.

Thanks,
Mike

[r1ch4rd]

Hi Mike,

Great, thanks very much, that's very helpful.  I'll try the quick method of putting the base64 encoded content in as a POST variable, although I have no idea how that scales   Otherwise I'll move onto the other two methods.

I don't suppose (I notice your "Alfresco Engineer" status) that a good feature request would be for more complete HTTP handling to the web scripts, is it?  I can't see how as you would write good RESTful web services using the web scripts without these facilities.  For example, a number of standards use header fields or even extensions as part of the protocol, which are currently inaccessible to us here.

All the best,

Richard

[mikeh]

It's an area we've been thinking about - and have recently done some refactoring around reading of the request body. The issue is that we don't want to do any unnecessary parsing, processing, or caching of the request body until it's certain (a) what format it's in and (b) whether it's even required.

We currently process multipart/form, form POST, JSON and CMIS (ATOM) bodies depending on the webscript extension, using different readers. For your case where the file's content is in the body, it makes sense to create a new reader - e.g tied to ".file.js" webscript extensions - which would present the request body's content as a content stream suitable for writing to a file to the JavaScript runtime.

Your other request is for access to arbitrary request headers? This is probably something we can look at as an improvement.

In either case, please raise enhancement issues in JIRA so they can be properly prioritised. Unless you fancy tackling it yourself and contributing back  :wink:

Thanks,
Mike

[romain_lamarche]

A "quick and dirty" solution is to specify "<format default="atomfeed">extension</format>" in the description file of your webscript.
For me, it works with Alfresco 3B, and the form data is in the variable "query".

Then, for example, you can parse it as XML, look into the file "query.post.cmisquery.js" for parsing it.

[davidc]

Request headers are available via the root objects:

headers
headersM

The latest HEAD and 3.0E also provide access to the request body via the root object:

requestbody

This object may be used as a parameter to the write method.  Also supports the properties content (for converting to a string, if possible), encoding and mimetype.

There are several web script enhancements in 3.0 that have yet to be documented in the wiki.  We'll get there as soon as we can because there's some good gems hidden hiding in there.