enctype problem in CGI

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

Monks,

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;
[download]

and it creates the following

<!DOCTYPE html
	PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>macCopy</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<form method="post" action="myAction.pl" 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

Comment on enctype problem in CGI Download Code

Replies are listed 'Best First'.
Re: enctype problem in CGI by merlyn (Sage) on Mar 27, 2005 at 00:38 UTC
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.	[reply]
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]
Re^3: enctype problem in CGI by merlyn (Sage) on Mar 27, 2005 at 01:02 UTC
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]
Re^4: enctype problem in CGI by macPerl (Beadle) on Mar 27, 2005 at 01:20 UTC
Re^5: enctype problem in CGI by BrentDax (Hermit) on Mar 27, 2005 at 19:39 UTC
Some notes below your chosen depth have not been shown here
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">` [download] and I get the same thing if I omit -enctype=>&CGI::URL_ENCODED. I get the same with Perl v5.8.0 (Activestate) chas	[reply] [d/l]
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=>"myAction.pl"); # <form method="post" action="myAction.pl" # enctype="application/x-www-form-urlencoded"> print $q->start_form( -method => 'POST', -enctype => &CGI::URL_ENCODED, -action=>"myAction.pl"); # <form method="post" action="myAction.pl" # enctype="application/x-www-form-urlencoded"> and print $q->start_form( -method => 'POST', -enctype => &CGI::MULTIPART, -action=>"myAction.pl"); # <form method="post" action="myAction.pl" enctype="multipart/form-dat +a"> [download] 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. Boris	[reply] [d/l]
Re^2: enctype problem in CGI by chas (Priest) on Mar 27, 2005 at 00:47 UTC
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 CGI.pm that I have (2.752 I believe.) chas	[reply]
Re^2: enctype problem in CGI by macPerl (Beadle) on Mar 27, 2005 at 00:47 UTC
Boris 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 ?	[reply]
Re^3: enctype problem in CGI by borisz (Canon) on Mar 27, 2005 at 00:55 UTC
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=>"myAction.pl");` [download] Boris	[reply] [d/l]
Re^4: enctype problem in CGI by macPerl (Beadle) on Mar 27, 2005 at 01:07 UTC
Re^5: enctype problem in CGI by borisz (Canon) on Mar 27, 2005 at 01:16 UTC
Some notes below your chosen depth have not been shown here
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. --Artist	[reply]
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">` [download] 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	[reply] [d/l]
Re^2: enctype problem in CGI by avarus (Novice) on Apr 15, 2008 at 09:23 UTC
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 CGI.pm (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` [download] So if not a bug this is at least a big shortcoming in the CGI.pm 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' />` [download] 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. :-) TIM -- #Tip: use 'no strict' to make those nasty errors vanish.	[reply] [d/l] [select]
Re^3: enctype problem in CGI by macPerl (Beadle) on May 14, 2008 at 10:14 UTC
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	[reply]

Back to Seekers of Perl Wisdom