Bob, That's interesting. You know, I work with about 5 other perl programmers, most of which do use CGI.pm, but none of them use it for anything other that gathering input from the web. I have also downloaded many packages from CPAN, I would say a majority of them use CGI.pm, but very rarely do I see it used for anything but gathering data. I'm not suggesting we shouldn't follow the standard. I am suggesting that this particular standard will never be enforced, because if it was, I'd be willing to bet, it would break a great percentage of perl scripts out there. But yes, I agree with you that we should all try to follow the specs pretty closely. Anyway, personally, I don't use CGI.pm at all, and it would be a real shame if I began including the whole thing just for that. It would just seem smarter for me to begin using this print "Content-type: text/html${CRLF}${CRLF}"; instead. I created a lib for receiving data from GET, POST or shell. I will be releasing it to CPAN soon, and expect to get this sort of thing quite a bit. That is good, because I want my lib to be very efficient and proper. The reason I wrote my own is because I like my variables in a easy to use structure: %hash = ( 'a_name' => 'value', # for single name value pairs 'b_name' => ["multiple", "values", "for", "this"], # for single name muli-value sets 'c_name' => { 'original_name' => 'filename.jpg', 'size' => '23554', 'location' => '/tmp/fileupload/tmpfile-10028983-88.57.192.3-2783-298374-927837' } # for files ); With this structure, I can get to everything very easily. It didn't make much sense to use CGI.pm to gather the data, smush it into a data structure, only to loop through all the data and shove it into another structure. I'm sure I'll get lots of hate mail from CGI.pm die hard's, but my other choice is to just not post this at all. What I hope for is several people telling me how to make it slightly more efficient or compatible with other OS's (you see I've only had opportunity to test it on Linux and Win2000, though I've been testing it on Linux for about 2 1/2 years). Its pretty hard to make it more simple than: use Form; my %input = Form();
David ----- Original Message ----- From: "Bob Showalter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, June 25, 2002 11:12 AM Subject: RE: Displaying Problems > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 25, 2002 12:47 PM > To: Bob Showalter; [EMAIL PROTECTED] > Subject: Re: Displaying Problems > > > Ok, so here's the deal: > > "Some HTTP/1.0 software has interpreted a Content-Type header > without charset parameter incorrectly > to mean "recipient should guess." Senders wishing to defeat > this behavior MAY include a charset > parameter even when the charset is ISO-8859-1 and SHOULD do > so when it is known that it will not > confuse the recipient." > > By the way, I did not upper case the MAY and SHOULD, those > were that way in the doc which means they > were trying to emphasize them. I'd have to say that MAY > doesn't suggest that it is a requirement > for the content-type to work properly. This is the relevant paragraph from 2.2 that I was going for: HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7. Appendix 19.3 (Tolerant Applications) says, in part: The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR. But, section 3.7 says: When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body; a bare CR or LF MUST NOT be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries). Note especially the last sentence. A nit-pick, to be sure. But "little things" like this cause programs to break all the time. Like I said, most (maybe all?) clients will accept what you wrote, but why not stick to the standard? Or, save all the trouble of grovelling through the RFC's and: print $q->header; Cheers. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]