[cgiapp] Problems with uploads

[Nicholas Bamber]

Hi Nicholas

> >/ 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 
/> >/ manipulate it in javascript. I fixed that without spotting any other issues.
/>
> 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
> it.
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.
 
-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622