Message-Id: <199909291224.OAA22185@vals.intramed.rito.no> Date: Wed, 29 Sep 1999 14:31:02 +0200 From: Terje Bless <email@example.com> To: Gerald Oskoboiny <firstname.lastname@example.org> cc: W3C Validator <email@example.com> Subject: Re: [PATCH] use CGI.pm;('binary' encoding is not supported, stored as-is)
On 28.09.99 at 19:39, Gerald Oskoboiny <firstname.lastname@example.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.