Re: [PATCH] use CGI.pm;

On 28.09.99 at 19:39, Gerald Oskoboiny <gerald@w3.org> wrote:

>[...] this syntax doesn't seem to be supported by CGI.pm:
><URL:http://validator.w3.org:8000/check?uri=http://www.w3.org/;ss;sp;outline>
>and I'm not sure how to fix that. It wants '=' after the parameters, or
>else they don't get defined.
>
>This works:
><URL:http://validator.w3.org:8000/check?uri=http://www.w3.org/&ss=&sp=&outline=>
>
>Any ideas how to support the old syntax as well?

Found & Fixed, but...

...I'm not quite willing to accept this as a bug in /my/ code yet
(allthough I should of course have caught this in testing).

CGI.pm is returning an empty string for "p=", but 'undef' for "p".
Depending on whether you view that as wrong or merely inconsistent, this is
either a bug or a mis-feature.

Also, from reading the HTML 4.0 specification, I'm under the distinct
impression that that calling convention is wrong. It doesn't spell it out,
but it implies that there should _allways_ be a value for each parameter;
even if that value is the empty string. Nowhere does it suggest the
existance of a pure boolean parameter type or that "p=" == "p".

I'll take the CGI.pm issue to it's maintainer to get his opinion and I'd
appreciate it if you'd take the specification issue to the right person at
W3C (I'd do it myself, but I don't know who to contact). I may be utterly
wrong where CGI.pm's behaviour is concerned, but the HTML specification
really should address this; even if just to say "booleans may occur".


BTW, does anyone know if there are User Agents that will send a parameter
from a form (a checkbox, say) even if that parameter hasn't been set?


I'm attaching a patch against
<URL:http://validator.w3.org:8000/dev/check-current.txt> (as of around
10:30am UTC today) that will work around this problem. Regardless of what I
think of it, it's clear that this is too important a compatibility concern
to drop this support; assuming my take on the issue is even correct.

The patch contains a few other mods that aren't strictly necessary. I was
fiddling with a few other things and figured I'd just include them. They
make no significant difference and are easy to delete if you don't like
them.

I also changed a few 'if' tests in light of the new behaviour. Not strictly
necessary either, but it makes it clearer what's being tested against.


The workaround I came up with is to loop over all given parameters and set
each to a boolean true value if it wasn't allready boolean true. This fixes
the current problem, but will introduce a new problem if there are UAs that
send unselected parameters from forms as empty strings. The spec doesn't
really cover this very well, but my interpretation is that the UA would be
in error in this case.

This is why the 'if' tests changed, BTW. It's confusing to test whether
something is 'defined' when you loop over all parameters and explicitly
make them not only defined, but "true" as well. Better to test if they
evaluate as "true"; less confusing and you can set them to "false" if you
later want to override them.