In a message dated 2/20/2002 12:00:16 AM Eastern Standard Time,
[EMAIL PROTECTED] writes:
Before you do and spend a lot of time coding form.tcl in C though,
I would recommend seeing what the AOLServer head is doing. I didn't
examine it closely, but it's only about 20 lines of Tcl now.
[ Please note that there is an ongoing discussion of the problem on the
thread: dstringcachemaxentries, dstringcachemaxsize, iobufsize: how are
they related?]
I am testing the file upload using ns_conncptofp, not ns_queryget; in fact,
I don't use any of the procedures in the modules/tcl/form.tcl
I think I should have been a little more clear about what I meant by
headers. See, there are headers for the entire page, but each part of
the multi-part form can also have a set of headers, usually just
Content-Type and Content-Encoding if relevant. Netscape doesn't seem to
send any of them
...
If each part of a multi-part form had a Content-Length, there would be no
reason to parse for the boundary strings. There would, in fact, be little
need for boundary strings at all. I'm not entirely clear on why it was
done with boundaries instead of lengths in the first place.
This is correct. However, the form.tcl is not optimal code. You
don't need to go through and search each line. You start at the
beginning and break into parts by doing
string first \n$bound\n $string
I thought about this. There's no reason it wouldn't work, but you'd have
to be
Could we keep this discussion under one thread please?
The dstringcachemaxentries... thread contains all the relevant details in
my quest to troubleshoot this problem.
Thanks everybody for your interest and your willingness to help!
See you in the dstringcachemaxentries... thread! ;-)
Simos.
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
...
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.
It looks like the aolserver HEAD code does something different,
as form.tcl shrank a lot, however ...
OK, I uploaded a 2 meg file.
aim: scottgnet
- Original Message -
From: Rusty Brooks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 18, 2002 3:24 PM
Subject: Re: [AOLSERVER] File uploading
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
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
Sorry about that last one not having a subject. I changed email clients
and the new one generates a Sender: header that listserv won't take
(because it doesn't match what I registered with). So it's all cut and
paste.
I was curious so I went and looked:
my original test had 227,000 lines
my
We had a 250MB file with around 1.5M lines of 170 bytes each. A TCL
program to read this file in a ~10-line loop with a few if tests, a
handful of string commands (trim, length, compare), and setting an
ns_share array took 365 seconds. The exact same thing in a 20-line
C program took 40
Here are the headers passed by MSIE 5.5 one of my upload tests. Note that
Content-length is set. I expect most browsers do this properly with
multipart/form-data.
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
13 matches
Mail list logo
