Fog Creek Software
Discussion Board




setting form's enctype to 'multipart/form-data'

is causing NONE of my input values to reach a perl script whatsoever

I don't get it

I have a web form much like the form used here to post messages.  Previously, the FORM element had no ENCTYPE attribute.

Then I got the bright idea to add the ability to attach a file to a message, since all my users are registered, screened, known, and trusted.

so, I added  enctype='multipart/form-data' to the FORM element, as required.  And then added an INPUT with a TYPE of 'file'.  Then I did the necessary coding in the cgi script to write the file out to a buffer on the server drive.

BUT

with the ENCTYPE attribute in place, my script acts as though ALL the fields on the form have been left blank.  As a test, I removed the ENCTYPE attribute but left the file INPUT, and all the code changes to the script.  Now the form data flows through as usual, except of course no file data gets sent.

where am I going wrong, here?

muppet from madebymonkeys.net
Thursday, June 17, 2004

aha.. or I could just be an idiot

that's more likely

I think this isn't as simple as I thought, after reading through some RFC's.

:P

muppet from madebymonkeys.net
Thursday, June 17, 2004

I've written Java code that manually parses a multipart/form-data encoding. However, the encoded submit request is generated by a VoiceXML interpreter, instead of HTML. VoiceXML is a language for speech apps.

I've found that different VoiceXML platforms encode multipart/form-data slightly differently. My parser takes a few configuration parameters to handle those differences correctly.

Julian
Thursday, June 17, 2004

You are using METHOD="POST" aren't you.

Here's a CGI upload example in perl: http://www.wiley.com/legacy/compbooks/stein/text/upload.txt

Matthew Lock
Thursday, June 17, 2004


> I think this isn't as simple as I thought,
> after reading through some RFC's.

Darn right about that one! Without the ENCTYPE attribute, the data from the form goes to the Web Server in URL encoded format (name=value pairs separated by & and special characters replaced by %xx).

But once you set the ENCTYPE attribute to "multipart/form-data", the data is no longer sent in URL encoded format. Instead, it is sent in MIME format. To get the input values now, you need to write a new parser that can parse the contents in the new format.

Check out the following RFCs to know more about the MIME format in which data is sent to the Web Server:

http://www.faqs.org/rfcs/rfc1867.html
http://www.faqs.org/rfcs/rfc2388.html

T-90
Thursday, June 17, 2004

I want to try and do this WITHOUT CGI.pm

I've managed to avoid that library in my site software thus far (5 years) and I'm not about to break down and include it for this one little function :)

I guess I'm writing a parser, next.

muppet from madebymonkeys.net
Thursday, June 17, 2004

Best of luck! Get back if you require any assistance in implementing the parser.

T-90
Thursday, June 17, 2004

thanks much for your assistance!

I'm already rewriting/porting my site portal to PHP, so I may just scrap this feature for now and wait to implement it in the new version.  File uploads are a bit easier to handle in PHP thanks to a lot of built in functionality.

muppet is now from madebymonkeys.net
Thursday, June 17, 2004

> I want to try and do this WITHOUT CGI.pm

You're a nutcase if you don't want to use CGI.pm. Why reinvent the wheel. Lincon Stein has spent years tweaking CGI.pm to work with all the different browsers and servers out there. And it's html controls a brilliantly convenient.

Matthew Lock
Thursday, June 17, 2004

> File uploads are a bit easier to handle in PHP thanks to a lot
> of built in functionality.

Gimme a break CGI.pm ships with standard perl and it's this many lines to get the filename:

$filename = $query->param('uploaded_file');

and the file is accessible through: <$filename>

Matthew Lock
Thursday, June 17, 2004

I find CGI.pm awkward and clunky to use.  But thank you for the nutcase comment.

I've been working on perl/CGI for over 5 years now and never, not once, have I used CGI.pm.  I've gotten along swimmingly.

I am acquainted with two other perl developers who, like me, dislike CGI.pm and have NEVER used it.  They're doing fine, too.

If you like it, great.  Use it all you like.  Declaring other people insane for not agreeing with your love of it puts you squarely in the "Linux Zealots and other Wackos" box in my mind.

Nice talking with you.  =)

muppet is now from madebymonkeys.net
Thursday, June 17, 2004

not to mention, now that this portal has been developed for 5 years without any use of CGI.pm whatsoever, to suddenly change direction and incorporate that library means an approximately 75% rewrite.  Why in the Hell do I want to expend all that effort so that after about 8 months of intense coding, I can now use two lines to upload a file?

muppet is now from madebymonkeys.net
Thursday, June 17, 2004

> I've been working on perl/CGI for over 5 years now and
> never, not once, have I used CGI.pm.  I've gotten along
> swimmingly.

> I am acquainted with two other perl developers who, like
> me, dislike CGI.pm and have NEVER used it.  They're doing
> fine, too.

Since you lot have NEVER used CGI.pm maybe you don't know what you are missing. In my opinion CGI.pm gives perl the best CGI support of any platform out there. You may be doing fine, but why waste your time rolling your own when you could be working on what's actually unique about your code?

Matthew Lock
Thursday, June 17, 2004

By the way how could you have found CGI.pm arkward and clunky to use, and at the same time NEVER, not even once,  used it?

Matthew Lock
Thursday, June 17, 2004

When I say I've never, not once, used it, I mean in any completed project.  I'm sorry, I could have been more clear.

I will admit that I usually prefer to roll my own code over using vast libraries authored by someone else.  I don't think there's anything wrong with that.  It's not as though this project is for an employer with time or budget constraints.

muppet is now from madebymonkeys.net
Thursday, June 17, 2004

There's nothing wrong with being cautious about using other people's code, but CGI.pm has been a trusted part of perl since the mid nineties. And the code is open source so you can check it if you wish. I just hate to see people waste time with the arcane matters of file uploading when a free module solved all those problems almost a decade ago.

Matthew Lock
Thursday, June 17, 2004

I understand what you're saying, but it's silly for you to argue with me in a thread where quite early on I declared that I am:

1. aware of CGI.pm and all it's wonderfulness
2. not willing to use CGI.pm in this instance

Thank you T-90, for actually posting something helpful given the parameters of my question.

muppet is now from madebymonkeys.net
Thursday, June 17, 2004

Not knowing fully the reasons you don't want to use CGI.pm, I'll assume that it might be because its too much code to load for one little function.

You might want to look at CGI::Simple then.  Its a trimmed down version of CGI.pm, that just does the basics.

I use it for all file and parameter input, and then output everything with Template Toolkit.

Or, roll it yourself, this is just a suggestion :-)

Andrew Hurst
Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home