Loading ...
Sorry, an error occurred while loading the content.
 

Re[2]: multipart/form failure

Expand Messages
  • Alex Oboimov
    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
    Message 1 of 4 , Sep 1, 2004
      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@...



      --
      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
    • Randy Kobes
      ... [ ... ] ... 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
      Message 2 of 4 , Sep 2, 2004
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.