Uploader, Gears, and multipart POSTs

[Antranig Basman]

The POST data from Gears is limited by the API to consist purely
of a file slice. You have arbitrary control over headers, but
there is not sufficient leeway in the API to compose a proper
formenc multipart request - in particular, a POST body may not
consist of any more file slices than one, nor can you add
the required slice boundaries.

Basically this means it is impossible to emulate the wire
traffic of a standard browser submitting a file upload
set using the current Gears API... so it could as it stands
not be used in conjunction with any existing backend. I agree
with Colin that since this would substantially limit the
appeal of the component to most of our users, that we should
concentrate on improving the Flash uploader for now and
wait for a refreshed release of Gears.

Cheers,
Boz.

Jacob Farber wrote:
>
> So, just out of curiosity, what does the POST data from Gears look
> like? How is it structured?
> Jacob
>
> On Thu, Feb 12, 2009 at 10:15 AM, Colin Clark <colin.clark at utoronto.ca> wrote:
> >
> > Hey everyone,
> >
> > As you know, I've been playing around with the latest version of Google Gears, which provides support for multi-file uploads. I was hoping to use it in as an alternative to the Flash back end in the Uploader, since we've somewhat disappointed by the accessibility of Flash 10.
> >
> > Gears provides a pretty good API for uploads. Compared with the code required to bootstrap SWFUpload, I was able to implement a preliminary version of the code with significantly fewer lines of code. Gears also provides some intriguing forward-looking features, such as the ability to do offline uploading and to pause a file and resume it much later on.
> >
> > I hit a snag with Gears the other day, though. Anyone who's built a standard HTTP file upload will be familiar with how they work. In short, the client makes a POST request to the web server. The request needs to have a content type of "multipart/form-data" so that the server knows how to correctly process it.
> >
> > Adobe, who aren't famous for following Web standards, did the right thing in Flash. They compose a valid multipart POST request when sending files to the server. Thus you don't need to write any special server-side code to handle Flash-based multi-file uploads (with a few caveats, perhaps).
> >
> > On the other hand, Gears doesn't allow you to make multipart POSTs. As a result, users of the Uploader component would be required to write a separate, Gears-specific handler on the server. Given that we've always imagined that Gears support would be a "progressive enhancement" on top of our support for Flash and plain old HTTP uploads, I'm not sure this is going to make our users very happy.
> >
> > For now, I'm figuring we're best to shelf Gears support for the Uploader and see if we can implement a couple of hacks to make Flash 10 more keyboard-friendly. From what I've seen, Google is aware of the multipart POST issue in Gears and has a fix coming eventually. At that point, we can pick this work up and release it in a future version of Infusion.