Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

enctype problem in CGI

by macPerl (Beadle)
on Mar 26, 2005 at 23:41 UTC ( #442565=perlquestion: print w/replies, xml ) Need Help??

macPerl has asked for the wisdom of the Perl Monks concerning the following question:


Using CGI I have the following code

#! /usr/bin/perl use CGI; use strict; my $q = new CGI; print $q->header; print $q->start_html(-title=>'macCopy'); print $q->start_form(-enctype=>&CGI::URL_ENCODED, -action=>"myAction.p +l"); print $q->submit(-name=>'submit', -value=>'GoForIt'); print $q->hidden('hidKey','hidVal'); print $q->endform; print $q->end_html;

and it creates the following

<!DOCTYPE html
	PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="" lang="en-US" xml:lang="en-US">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<form method="post" action="" enctype="multipart/form-data" enctype="application/x-www-form-urlencoded">
<input type="submit" tabindex="1" name="submit" value="GoForIt" /><input type="hidden" name="hidKey" value="hidVal"  />
</form> </body> </html>

Please note the "enctype" in the FORM tag

I am looking for enctype ="application/x-www-form-urlencoded"

When I omit the -enctype=>&CGI::URL_ENCODED option in start_form to try to get the default value (which should be application/x-www-form-urlencoded)it still defaults to enctype="multipart/form-data"

Can anyone put me right and explain why this is happening ?

Thanks in advance

Replies are listed 'Best First'.
Re: enctype problem in CGI
by merlyn (Sage) on Mar 27, 2005 at 00:38 UTC
    The latest 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 itself).

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

      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 version 3.07. Is that not a bug in


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

      What does this mean ?


        What does this mean ?
        This means, why do you care? {grin} As long as you're generating the form with, and also interpreting the form with, 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.

Re: enctype problem in CGI
by chas (Priest) on Mar 27, 2005 at 00:16 UTC
    Using Perl v5.6.1 (Siemens build) on Windows 98, and your exact code, I get:
    </head><body><form method="post" action="myAction.p " enctype="applica +tion/x-www-form-urlencoded">

    and I get the same thing if I omit -enctype=>&CGI::URL_ENCODED.
    I get the same with Perl v5.8.0 (Activestate)
Re: enctype problem in CGI
by borisz (Canon) on Mar 27, 2005 at 00:22 UTC
    It works fine for me. IE:
    print $q->start_form(-method => 'POST', -action=>""); # <form method="post" action="" # enctype="application/x-www-form-urlencoded"> print $q->start_form( -method => 'POST', -enctype => &CGI::URL_ENCODED, -action=>""); # <form method="post" action="" # enctype="application/x-www-form-urlencoded"> and print $q->start_form( -method => 'POST', -enctype => &CGI::MULTIPART, -action=>""); # <form method="post" action="" enctype="multipart/form-dat +a">
    I noticed that your output has two enctype attributes and your for has a POST method but your code does not have it. I doubt that the output is from your code.
      I get the method="post" with the OP's code. That seems to be the default if you didn't specify a method, at least in the version of that I have (2.752 I believe.)


      That IS the output from the code.

      POST is the default method - so the fact that my code does not have it means nothing.

      If you re-read the my post you will see the ENCTYPE is the source of my confusion. Of course there should only be one. Of course, the default should be "application/x-www-form-urlencoded".

      Any other ideas ?

        Yes, use the encoding type explicit in your code. Since it looks, the default has changed.
        print $q->start_form( -enctype => "application/x-www-form-urlencoded", -action=>"");
Re: enctype problem in CGI
by artist (Parson) on Aug 29, 2006 at 15:45 UTC
    I am having similar problem with version 3.15. To my surprise 3.11 works fine. I am looking for solution.
Re: enctype problem in CGI
by thewebsi (Scribe) on Nov 13, 2007 at 02:02 UTC
    It's quite strange, and does seem like a bug. I don't have access to a newer version of CGI just now, so not sure if it's been fixed (no reference to it in the change log). But I did find a workaround for anyone who's interested:
    >perl -e 'use CGI; print $CGI::VERSION;' 3.15 >perl -e "use CGI; print CGI::start_form({enctype=>'test'});" # Seems +broken <form method="post" action="" enctype="multipart/form-data" enctype="t +est"> >perl -e "use CGI ( -no_xhtml ); print CGI::start_form({enctype=>'test +'});" # A non-ideal solution <form method="post" action="" enctype="test"> >perl -e "use CGI; print CGI::startform({enctype=>'test'});" # Don't k +now why it works, but it does... <form method="post" action="" enctype="test">
    Note that startform() is documented as an alias of start_form(), and the source code does seem to support that. I also got the same results with v3.11
      I've just found this thread very useful so even though it is probably no help to the original poster I'll add another comment. The reason the suggested workaround works is pretty obvious with a glance at (line 1802 in my version 3.15):
      #### Method: start_form # synonym for startform 'start_form' => <<'END_OF_FUNC', sub start_form { $XHTML ? &start_multipart_form : &startform; } END_OF_FUNC
      So if not a bug this is at least a big shortcoming in the documentation, which claims that startform is a simple alias for start_form.

      And for all the numbnuts above who said "why not just use multipart every time". What??? Multipart encoding only works with POST. If Firefox sees:

      <method='get' enctype='multipart/form-data' />
      Then it ignores the encoding with a warning, and probably does what you want, but Konqueror will honour the encoding and ignore the method. Hence all your forms get POSTed. Hence if I have a simple search box on my site Konqeror users can't can't bookmark the results page, and if I hit reload I get a spurious warning about resubmitting form data. Vanilla GET/url-encoded forms are in the HTML spec for a reason and seeing comments along the lines of "I don't need them so you shouldn't either" makes me wonder what this community is coming to.

      OK, sorry, rant over. :-)

      #Tip: use 'no strict' to make those nasty errors vanish.

        I've moved away from Perl as a result of the underlying weaknesses which this issue uncovered for me.

        The success (for me, my business) of Perl as a development platform is critical to the support available, the reliability of the modules and inherent in both those, the community (e.g. perlMonks).

        For a long time, I not only enjoyed working in Perl, I really enjoyed being "part" (ok ... an "extra" of very small stature!) of the Perl community.

        However, when I came across the above issue it showed that there are issues with reliability and documentation (support). To be honest I think I could have managed with both of those if it hadn't been the attitude of more "senior" members who displayed no willingness to deal with anomaly - or gave no direction on resolving it.

        The fact that, 3 years later, this post is still being of some assistance/interest strongly supports this view.

        In retrospect, I'd still be a perl advocate if it had panned out differently: e.g.
        • problem highlighted
        • source of issue identified
        • minor tuition/wrist slap for me for hand-rolling
        • update of module and/or documentation
        • thread closed forever

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://442565]
Approved by moot
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2022-05-16 21:34 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (63 votes). Check out past polls.