Yes, Content-Length can and should be used by multipart/form-data. Here's a
snippet from my https.tcl ns_httpspost proc which sets the Content-length
header before doing the POST:
if {$type == "multipart/form-data"} {
...snipped...
append querystring "--${boundary}--\n"
ns_set put $rqset "Content-length" [string length $querystring]
...snipped...
}
If form.tcl isn't checking the Content-Length in the header, let's change
it.
/s.
-+-+-+-+-+-+-+-+-+-+-+-+-
If to err is human, I must be more human than most.
Scott S. Goodwin
u: http://scottg.net
e: [EMAIL PROTECTED]
p: 850.897.6830
aim: scottgnet
----- Original Message -----
From: "Rusty Brooks" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 18, 2002 3:08 PM
Subject: File uploading
> Take a look at
> modules/tcl/form.tcl
> in the AOLServer distribution. It is actually responsible for handling
> the
> uploaded files. It's not the speediest thing in the world, and I'm pretty
> sure this is the problem.
>
> For example, it examines *every line* of the incoming file to see if it
> matches the multipart boundary. For a large file this could be very
> onerous.
> Look at _ns_parseformfp, for example.
>
> I wonder -- does the multipart standard allow for a Content-Length
> parameter? That certainly would be helpful since the line-by-line parsing
> is just used to find the byte offset where the file starts.
>
> I'm going to look into this a bit and see if it actually is the
> problem. If
> so it may help to make form.tcl into a C module to speed things up.
>
> Darren Ferguson wrote:
> >
> > Network problems. 1 Meg is 1 Meg when being transfered across a network
> >
> > It should probably not be that slow but i would be inclined to look at
> the
> > network and see if it drops a lot of packets etc
> >
> > Darren
> >
> > On Mon, 18 Feb 2002, Simos Gabrielidis wrote:
> >
> > > Here are the results of the various file sizes and timings:
> > >
> > > 30KB: 0.28 sec, 60KB: 0.57 sec, 100KB: 1.1 sec, 1000KB: 13.41
> secs,
> > > 1500KB:19.47 secs, 3000KB: 37.74 secs, 4000KB: 50.56 secs,
> 6000KB: 74.82
> > > secs.
> > >
> > > Any ideas?
> > >
> > > Thank you,
> > >
> > > Simos.
> > >
>
