[cgiapp] Problems with uploads
nicholas at periapt.co.uk
Fri Jun 25 06:07:51 EDT 2010
> >/ A lot of my troubles seem to have come from following the "HTML, XHTML,
/> >/ and CSS Bible" by Steven Shafer which recomends a form like this:
/> >/ <form action="formhandler.cgi" method="post" enctype="form/multipart">
/>/ />/ <input type="file" id="file" size="10"/> ......
/> >/ I was slightly puzzled by the use of an "id" attribute rather than a
/> >/ "name" attribute, when I want to read from this control rather than
> There is nothing wrong with the id. I always use name and id, myself,
> and make them the same value.
> JS code will often require the id, so you should always include it.
I thought this pretty much sums it up. http://www.velocityreviews.com/forums/showpost.php?p=699631&postcount=2
So I only include when I have CSS or js stuff to hang on it.
> >/ It took me a long time to realize that the browser was sending
/> >/ CONTENT_LENGTH = 13. I could have spotted this with
/> >/ CGI::Application::Plugin::DevPopup::HTTPHeaders which I was using, but I
/> >/ did not make the connection until I was actually reading the CGI source.
/> >/ When I removed the size attribute this problem went away.
/> >/ The second problem was that the enctype should be "multipart/form-data"
/> >/ not "form/multipart". Fixing that got a CGI::Application file upload
/> >/ working.
> That's a nasty bug to publish. And size 10 seems very narrow-minded.
> You should be justifiably suspicious of any other code in the book.
Whilst not wanting to rollback on the on the inaccuracy of the text, I should say it was a paraphrase.
The text did not specify an actual size, but my understanding is that this size relates to display length of the control, and so
should not influence what CONTENT_LENGTH parameter is send to the browser.
> Most people don't have problems. It's always difficult to know exactly
> what set-up the user was using.
> But the bug reports /already/ tell us what needs work. If you can figure
> out a patch, I'm sure the author of CGI would be delighted to receive
Oh dear. Where shall I start? Shall I start a Rumsfeldian rant? Or shall I just direct you to lists of quotes about programming
(http://www.quotegarden.com/programming.html). Or shall I say "Okay. Let's get this right. You are saying that the list in bugzilla can be relied
upon to be a complete list of all bugs in CGI.pm. And all we need to do is fix those 63 and then we will have web nirvana."
Actually I find the statement "If you can figure out a patch, I'm sure the author of CGI would be delighted to receive it." most terrifying, because presumably
as far as the authors of CGI know, I could be some crazed maniac (if this email does not confirm such suspicions) and I do hope the contributions get thoroughly reviewed.
Then I could go on to point out that CGI.pm is sitting in the middle of what used to be a standards war zone and still is a ignorant,
innocent good guys versus clever, devious bad guy hackers war zone.
Does anyone still use in Server push - at least in the
old sense? It is riddled with legacy (or war wounded?) code, maintains both an OO and a functional interface, compiles stuff on the fly, can be used in hundreds
of different ways and so on.
Actually whilst I looked through the bug list I noticed at least one person saying it used to work in version X but does not work now.
The overall coverage figure seems to be 76%. So that leaves 24% of the code base that could be broken from one release to the next. I would have thought
as such contributions that improve test coverage would be a lot more welcome than patches to bugs.
Ph: 0421 920 622
More information about the cgiapp