in reply to enctype problem in CGI

The latest CGI.pm uses multipart/form-data for both start_form and start_multipart_form. This shouldn't be a problem for conforming CGI server interpreters (such as CGI.pm itself).

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re^2: enctype problem in CGI
by Errto (Vicar) on Mar 27, 2005 at 04:16 UTC
    You are right, of course, but it seems to me that there might be legitimate reasons for wanting to use the old urlencoded approach, such as if one needed to post a form to another site that runs an inferior platform. And I verified the OP's observation that setting -enctype explicitly in start_form does not override this default. This is CGI.pm version 3.07. Is that not a bug in CGI.pm?
[reply]
[d/l]
Re^2: enctype problem in CGI
by macPerl (Beadle) on Mar 27, 2005 at 01:00 UTC

    merlyn

    I checked the Change.log and didn't spot any reference to this.

    Don't understand ...

    This shouldn't be a problem for conforming CGI server interpreters (such as CGI.pm itself)

    What does this mean ?

    Thanks

[reply]
      What does this mean ?
      This means, why do you care? {grin} As long as you're generating the form with CGI.pm, and also interpreting the form with CGI.pm, and using a modern browser, this all works nicely together.

      If you're doing something dumb like writing a hand-rolled CGI interpreter to handle the incoming form, this breaks it. Oh well. Shouldn't be doing that, anyway.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

[reply]

        Ok - with you on that.

        Doesn't explain:

        the 2 enctype entries in the FORM tag

        the inability to override the default

        The lack of reference on the Changes.log

        And it is being handled by a dumb hand-rolled CGI interpreter - which I don't think is a fair scapegoat for this issue.

[reply]

In Section Seekers of Perl Wisdom