On Fri, Apr 02, 2004 at 11:58:20AM -0800, David Byron wrote:
> On Fri, 2 Apr 2004, Dan Fandrich wrote:
> > > $ ./curl http://place_to_upload -F "File=@<filename>" -F "foo=bar"
> > > --compressed zlib
> > >
> > > and some more -F's, in case that matters.
> > >
> > > Any pointers of how to dive in and do this, some suggestion
> > > of how to change the command line so that this is easier to
> > > add?
> >
> > For the command-line client, extending the meaning of the
> > existing --compressed option to enable compression of
> > uploads makes perfect sense to me; I don't think you need a
> > new command-line option.
>
> I should have been more clear. I'm assuming that compressing multipart
> forms is harder than compressing other kinds of uploads. So, I was asking
> if I could change the curl command line I was using so that adding
> compression would be easier.

At the HTTP level, multipart forms look like any other upload. All of the
parts are concatenated and sent in one chunk; the Content-Encoding which
applies to any one part must apply to them all, so you can't compress just
one part of an upload. I still don't think you need richer compressed
upload syntax beyond the presence or absence of a --compressed flag.

> But, I guess what I'm really looking for are pointers in the code so I know
> where the work needs to be done.

Sorry, I haven't looked into this. If you want to do it right, though, you'll
have to remember to look for a 415 error code from the server which
it will send if it can't handle compressed uploads. You may want
to optimize this negotiation by using an Expect: 100-continue before
starting the upload.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved