Howdy, Randy.

You wrote 1 sept 2004, 19:24:42:

RK> Are you using libapreq2 to handle the file upload?
RK> Or something else?

Sorry Randy I'm using my own script to parse form
data but it was thoroughly debugged in the old
system and used to work fine. Though I must admit
some strange behaviour - all files used to get
extra \r\n symbols, so I was forced to double
chop() the buffer before inserting it into
database. That worked for all types of files
equally.

RK> Does this problem arise for clients both on Unix and
RK> Windows? Is it browser-specific?

Alas, all my clients are windows based - never had
a chance to check Unix client's behaviour.

RK> Do you know at what stage the corruption in the .doc
RK> file occurs (eg, on upload, storing it in the database,
RK> or on download)?

Inspection of buffer content after the FORM
parsing shows that extra \r\n appear both in the
beginning and at the end of the file so I presume
the upload process is to blame.

RK> Do you know why the extra \r\n occur?

If I knew that I suppose I could find solution
easily.

RK> Normally these are an
RK> issue only with text files, in going between Unix and
RK> Windows - one might think that for binary files no such
RK> mangling need be done (as long as all appropriate handling
RK> of the files at all stages is done in binary mode, if
RK> applicable).

Text files constitute no problem - no one notices
presence of these \r\n symbols.

RK> If you don't chop(), is there a difference
RK> between how .doc and other binary (eg, .zip) files are
RK> handled?

If I don't chop (except for original double chop)
all binaries (zip, rar, pdf, jpg et al) are served
unchanged, only doc files acquire extra \r\n.

So, for time being I applied temporary solution
just to tame my clients. I inserted in my script
the lines 'if ($type='application/msword') {...}
just to cut out both leading and trailing \r\n's.
And it works!!

But I'm curious to find the source of the problem.
Plans: to use libapreq though I lack tutorial
texts concerning Apache::Request and mod_perl as a
whole.



-- 
Regards,
 Alex                          mailto:[EMAIL PROTECTED]



-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Reply via email to