$CGI::POST_MAX question

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

Dear Monks,

I have a script (actually a home grown module) that I am in charge of maintaining. It's function is to take in some text from several text fields, and grab an image from an "image upload" field. The text/image is then slurped into an html template and published to a local website. Yawn.

However, the users are noticing some weird behavior that is very hard to replicate. The users cull articles from various places on the web, copy/paste them into the text fields and grab their images and upload them using the tool. The weird behavior is that certain articles will not submit properly. There seems to be no difference that I could see, and the spaghetti code that is the module is very hard to figure out (rather than giving a good error message, it merely dumps one out to the GUI again, as though nothing had happened).

Then I tried removing a paragraph at a time from an offending article and submitting it. After I'd removed about half the text, it submitted properly. This leads me to think that it has something to do with $CGI::POST_MAX, which is currently set to CGI.pm's default.

My question: does $CGI::POST_MAX include the bytes of the file being uploaded as well as the text (in otherwords, is the binary data included in the POST_MAX)? If so, it could explain why certain articles are problems and other seemingly similar articles are not--their images are not as large.

Much thanks,

Chris

Comment on $CGI::POST_MAX question

Replies are listed 'Best First'.
Re: $CGI::POST_MAX question by BazB (Priest) on Dec 14, 2001 at 23:46 UTC
$CGI::POST_MAX does indeed include the file being uploaded - it's the entire post (a file is just uploaded as a multipart MIME POST, so any attachments are part of the post). This is mentioned in Ovid's CGI tutorial in Appendix 3, CGI documentation section (see Avoiding DoS attacks). These are just a reprint of the CGI docs Hope that helps Baz. Update: Fixed some typos, and added a link to the revelant section of Ovid's tutorial.	[reply]
Re: $CGI::POST_MAX question by jerrygarciuh (Curate) on Dec 15, 2001 at 00:49 UTC
I often find myself posting questions about problems and attaching a question like this one. What I keep trying to remind myself is that if I suspect that element X is at fault I should try a quick experiment which would tell me if I am correct. In your case I suspect that changing nothing in the scenario except for increasing POST_MAX would have given you your answer much faster than posting. I don't intend this as a flame at all but merely an meditation on saving myself effort (the virtue called laziness) which I myself need to contemplate. hth jg _____________________________________________________ If it gets a little bit out of hand sometimes, don't let it fool you into thinkin' you don't care.TvZ	[reply] [d/l]
Re: Re: $CGI::POST_MAX question by alienhuman (Pilgrim) on Dec 15, 2001 at 00:59 UTC
Point well taken jerrygarciuh. Thx to both of you for your comments/help. Chris	[reply]
Re: $CGI::POST_MAX question by alienhuman (Pilgrim) on Dec 15, 2001 at 02:59 UTC
UPDATE: After looking over perldoc CGI and looking at the code of CGI.pm, I've determined that the default for POST_MAX is no limit to the amount of information. Since then, I ran some more tests: the success or failure of the post seems to have only to do with the amount of data being sent in the text field. If I do not upload an image, and upload more than approx 4096 bytes of data in the text field, it fails. If I upload less than approx 4096 bytes in the text field, it succeeds, irregardless of image. I am scouring the web for information about a maximum amount of data for a given name=value pair... possibly a buffer size? If anyone has anything to offer here, much appreciated. Meanwhile, I'm re-writing this code to offer better debugging and looking at CGI::DebugVars. FURTHER UPDATE: I've since determined that the amount of data has nothing to do with the failure. I will investigate with various debugging tools and report back. Thx to everyone for your attention. Chris	[reply]
(crazyinsomniac) Re^2: $CGI::POST_MAX question by crazyinsomniac (Prior) on Dec 15, 2001 at 03:10 UTC
Ya know, CGI.pm isn't the only components involved in this transaction. There is this thing called a webserver, and it has all kinds of setting of its own. You might wanna look into those. Also, 4096 seems like a good limit for a GET request (i've seen it on a couple of servers). updated: and those tests you're running, they probably won't do any good, since nobody is mentioning which server they're running, or which version of CGI.pm, ~~you guys aren't on the same server~~ ;D, and CGI.pm is pretty dang sturdy. updated: I also sugguest the alienhuman goes and reads the RFC for HTTP, and then cracks open CGI.pm. In (crazyinsomniac) Re: A serious security problem with CGI.pm 3.01? I do that the post max limiting myself. ___crazyinsomniac_______________________________________ `Disclaimer: Don't blame. It came from inside the void` `perl -e "$q=$_;map({chr unpack qq;H;,$_}split(q;;,qH*));print;$q/$q;"`	[reply]