Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 22046
Status: resolved
Priority: 0/
Queue: CGI

People
Owner: MARKSTOS [...] cpan.org
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: Pod: correct default parameters of start_form
Download (untitled) / with headers
text/plain 268b
The CGI Pod states that the default enctype parameter of start_form is "application/x-www-form-urlencoded". This does not seem to be true: $ perl -MCGI=:standard -le 'print start_form' <form method="post" action="http://localhost" enctype="multipart/form-data">
Download (untitled) / with headers
text/plain 547b
On Thu Oct 12 05:14:40 2006, SREZIC wrote: Show quoted text
> The CGI Pod states that the default enctype parameter of start_form is > "application/x-www-form-urlencoded". This does not seem to be true: > > $ perl -MCGI=:standard -le 'print start_form' > <form method="post" action="http://localhost"
enctype="multipart/form-data"> Show quoted text
>
Funny enough using startform (without an underline), will use the other default: $ perl -MCGI=:standard -le 'print startform' <form method="post" action="http://localhost" enctype="application/x-www-form-urlencoded">
Download (untitled) / with headers
text/plain 1.1k
On Thu Oct 12 05:21:58 2006, SREZIC wrote: Show quoted text
> On Thu Oct 12 05:14:40 2006, SREZIC wrote:
> > The CGI Pod states that the default enctype parameter of start_form is > > "application/x-www-form-urlencoded". This does not seem to be true: > > > > $ perl -MCGI=:standard -le 'print start_form' > > <form method="post" action="http://localhost"
> enctype="multipart/form-data">
> >
> > Funny enough using startform (without an underline), will use the other > default: > > $ perl -MCGI=:standard -le 'print startform' > <form method="post" action="http://localhost" > enctype="application/x-www-form-urlencoded"> >
And another startform/start_form anomaly: if using three arguments to the function, then it behaves different: $ perl -MCGI=:standard -le 'print startform("GET", "/login", &CGI::URL_ENCODED)' <form method="get" action="/login" enctype="application/x-www-form-urlencoded"> $ perl -MCGI=:standard -le 'print start_form("GET", "/login", &CGI::URL_ENCODED)' <form method="get" action="/login" enctype="multipart/form-data" application/x-www-form-urlencoded> (The latter being completely broken). Regards, Slaven
Download (untitled) / with headers
text/plain 2.3k
On Thu Oct 12 05:25:19 2006, SREZIC wrote: Show quoted text
> On Thu Oct 12 05:21:58 2006, SREZIC wrote:
> > On Thu Oct 12 05:14:40 2006, SREZIC wrote:
> > > The CGI Pod states that the default enctype parameter of start_form is > > > "application/x-www-form-urlencoded". This does not seem to be true: > > > > > > $ perl -MCGI=:standard -le 'print start_form' > > > <form method="post" action="http://localhost"
> > enctype="multipart/form-data">
> > >
> > > > Funny enough using startform (without an underline), will use the other > > default: > > > > $ perl -MCGI=:standard -le 'print startform' > > <form method="post" action="http://localhost" > > enctype="application/x-www-form-urlencoded"> > >
> > > And another startform/start_form anomaly: if using three arguments to > the function, then it behaves different: > > $ perl -MCGI=:standard -le 'print startform("GET", "/login", > &CGI::URL_ENCODED)' > <form method="get" action="/login" > enctype="application/x-www-form-urlencoded"> > > $ perl -MCGI=:standard -le 'print start_form("GET", "/login", > &CGI::URL_ENCODED)' > <form method="get" action="/login" enctype="multipart/form-data" > application/x-www-form-urlencoded> > > (The latter being completely broken).
I've confirmed all issues to still be open with 3.43. To shed some light on it: startform() was the original method, and later "start_form() was added to supercede it, and apparently intended to have a better/smarter default enc type. It is is implemented like this: sub start_form { $XHTML ? &start_multipart_form : &startform; } The "completely broken" behavior shown last is really part of the normal handling of the HTML generators: It is trying to turn extra arguments into name/value attributes for the tag. It's not crystal clear to me the best way to resolve the mess. I think the best suggestion I have now is to make sure the docs refer to only "start_form() nearly everywhere, and document how it is intended to be used. Then just in one less visible place, we can document startform() as a historical method, which unfortunately has a slightly different behavior. Yes, it would be ideal if the worked the same, but I think we perhaps should leave the old startform() alone for backwards compatibility, the behavior of the newer start_form() is I think intentionally meant to be an improvement. Mark
RT-Send-CC: MARKSTOS
Download (untitled) / with headers
text/plain 438b
I'm going to start working on this. First, I want to declare startform() and endform() as DEPRECATED. They are the only two sub's that do not have an underscore. I going to fix the bugs and update the POD, hopefully without breaking any legacy code. Older versions of HTML allow that attributes did not always need an ="value" part but hopefully any code that does this uses only startform() (which I won't touch) so it'll still work.
Download (untitled) / with headers
text/plain 610b
On Wed Aug 19 15:13:07 2009, SHCOREY wrote: Show quoted text
> I'm going to start working on this. > > First, I want to declare startform() and endform() as DEPRECATED. They > are the only two sub's that do not have an underscore.
Sounds good to me. Show quoted text
> I going to fix the bugs and update the POD, hopefully without breaking > any legacy code. Older versions of HTML allow that attributes did not > always need an ="value" part but hopefully any code that does this uses > only startform() (which I won't touch) so it'll still work.
Sounds good. Automated tests are recommended to insure your bug fixes work as expected.
SHCOREY emailed me directly with patches for this. I'll review and apply them.
Download (untitled) / with headers
text/plain 111b
Thanks, This has been patched in my github repo now, although an extra peer review would be welcome. Mark
Subject: Thanks, released
Download (untitled) / with headers
text/plain 160b
The patch for this ticket has now been released in CGI.pm 3.47, and this ticket is considered resolved. Thanks again for you help to improve CGI.pm! Mark


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.