>>>>> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
Andrew> On Tue, Oct 17, 2000 at 10:34:42AM -0700, Randal L. Schwartz wrote:
Andrew> Ok. If the behavior won't change, may I suggest it be documented
Andrew> this way? With the warning that it should not be used for other
Andrew> purposes without due caution (and a pointer to alternatives).
I'm all for adding documentation on URI::Escape::uri_escape that says
that "if you are using this to construct a query-form URL, please
consider using URI's query_form() method instead, as the escaping
requirements are special".
Andrew> I see this code all the time. I debug this code all the time.
Andrew> Moreover, I don't think it's unreasonably at all. Constructing
Andrew> query strings isn't rocket science,
Apparently it is, because people are getting it wrong.
Andrew> and most CGI programmers have in
Andrew> their head, "escape the names and values, then separate them with =s
Andrew> and &s".
Just because most people are confused doesn't mean we shouldn't stay
with the standards. After all, these are probably the same people
that decode CGI using that hack-kneed code which tries to stuff every
parameter into a hash, blowing up checkboxes and multiple selects.
Andrew> Which is perfectly fine, except that the obvious candidate
Andrew> for "escape" doesn't (by default) support this use. That is
Andrew> surprising.
Not at all. It does the escaping for a URL, not the additional
requirements for a parameter within the query form because the normal
query processing uses & as an *additional* delimiter.
>> I don't think it helps to support WRONG practices,
>> especially if it might break CORRECT practices.
Andrew> Extra escaping will not break this practice (filename -> URI).
It's an *unnecessary* escaping in general. It hurts only after
the ?, which then has special escaping rules. Hence my suggestion
for the added documentation.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
