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]
