Re: multipart/form failure

[Randy Kobes <ra...@theoryx5.uwinnipeg.ca>]

On Tue, 31 Aug 2004, Alex Oboimov wrote:

> Hi folks,
>
> I'm fresh to Apache2/mod-perl2, just migrated from
> mp1.
>
> My system: Apache 2.049/Perl 5.8.4/mod_perl
> 1.99_14/DBI 1.42/DBD::InterBase/FireBird 1.5 on
> linux Mandrake 9.2 engine.
>
> My problem: my old programs were fine in the old
> system. Now after major editing of the programs
> they work except for files uploading that
> does not work properly.
>
> After parsing my multipart/form data I get $buffer
> with file's content, then I twice 'chop' it (for
> extra '\r\n' symbols) & put it in my SQL statement.
> The program executes fine but after downloading
> the file of 'application/msword' type is unusable
> while all other types (zip, rar, pdf, jpg et
> al) download just OK. The file becomes two bytes
> longer and is not recognized as .doc type.
>
> What the reason might be? I suspect that some
> settings in httpd.conf might preclude some sort of
> conversion for this sort of files. Any suggestions?

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

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

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

Do you know why the extra \r\n occur? Normally these are an
issue only with text files, in going between Unix and
Windows - one might think that for binary files no such
mangling need be done (as long as all appropriate handling
of the files at all stages is done in binary mode, if
applicable). If you don't chop(), is there a difference
between how .doc and other binary (eg, .zip) files are
handled?

-- 
best regards,
randy kobes

-- 
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

Re[2]: multipart/form failure

[Randy Kobes <ra...@theoryx5.uwinnipeg.ca>]

On Thu, 2 Sep 2004, Alex Oboimov wrote:

> 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.
[ ... ]
> 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.

It'd be interesting to try libapreq2 to see if using
this solves the problem. When using the Apache::Upload
tests on a Windows machine, it was quite easy to get
incorrect line endings on the uploaded files if the
appropriate binmode() on the filehandles was missing. The
current tests check for this, for both binary and text
files - a checksum is computed for a file, the file is then
uploaded and saved, a checksum is computed on the saved
file, and then these two checksums are compared.

libapreq2 is available from
   http://www.cpan.org/authors/id/J/JO/JOESUF/
After installation, one can use
   bash$ mp2doc Apache::Upload
to get basic information on using Apache::Upload. One
can also see example usage in the tests -
   glue/perl/t/apreq/upload.t
is what the "client" sends, and
   glue/perl/t/response/TestApReq/upload.pm
is the response of the server - this tests a number of
ways of getting at the uploaded file.

-- 
best regards,
randy

Re[2]: multipart/form failure

[Randy Kobes <ra...@theoryx5.uwinnipeg.ca>]

On Thu, 2 Sep 2004, Alex Oboimov wrote:

> 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.
[ ... ]
> 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.

It'd be interesting to try libapreq2 to see if using
this solves the problem. When using the Apache::Upload
tests on a Windows machine, it was quite easy to get
incorrect line endings on the uploaded files if the
appropriate binmode() on the filehandles was missing. The
current tests check for this, for both binary and text
files - a checksum is computed for a file, the file is then
uploaded and saved, a checksum is computed on the saved
file, and then these two checksums are compared.

libapreq2 is available from
   http://www.cpan.org/authors/id/J/JO/JOESUF/
After installation, one can use
   bash$ mp2doc Apache::Upload
to get basic information on using Apache::Upload. One
can also see example usage in the tests -
   glue/perl/t/apreq/upload.t
is what the "client" sends, and
   glue/perl/t/response/TestApReq/upload.pm
is the response of the server - this tests a number of
ways of getting at the uploaded file.

-- 
best regards,
randy

-- 
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

Re[2]: multipart/form failure

[Alex Oboimov <al...@soniir.samara.ru>]

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:alobo@soniir.samara.ru



-- 
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