[Maypole] 2.07 PR

Dave Howorth dhoworth@mrc-lmb.cam.ac.uk
Tue, 18 Jan 2005 12:56:22 +0000


I feel somewhat stupid. There was a new version of CGI::Untaint released 
after Christmas (apparently four versions on the same day), so we are 
talking about different code that behave very differently in the area we 
are discussing. It would have been helpful to mention it, I think.

Tony Bowden wrote:
> On Tue, Jan 18, 2005 at 11:30:50AM +0000, Dave Howorth wrote:
> 
>>(1) How does CGI::Untaint distinguish between a validation failure and a 
>>programming error (such as an uninstalled module)? The first should go 
>>to the browser, the other to the Apache log. The second is definitely an 
>>exception, but one could consume many pints deciding whether the first 
>>ought to be.
> 
> A validation failure is a very late check that occurs even after the
> regex check. They're both handled differently in the code. The
> uninstalled module problem will be caught much earlier.

It doesn't matter to me when it's caught! What matters is the end result 
and in both old and new versions the two cases are not distinguished. I 
think it would be sensible if programming errors like the uninstalled 
module caused CGI::Untaint to die, whilst validation failures caused it 
to return an error message. But they both used to make it die and they 
both now make it return an error message.

>>It's also not how it's supposed to work, according to the docs. is_valid 
>>is supposed to return a false value if validation fails, and 
>>CGI::Untaint's error method is supposed to return the message:
>>  "my $error = $handler->error;
>>If the validation failed, this will return the reason why."
> 
> Which is what happens. If we don't know why, we give a default error. The
> docs are missing the fact that you can throw your own execption here to
> provide a custom error message, but what happens doesn't contradict the
> docs AFAICS.

Well programs don't contradict the behaviour of non-existent docs either 
:) It's not the main point of docs to be not contradicted. In 
particular, when the behaviour of the code changes it's generally 
helpful for the docs to change at the same time to describe the features.

Cheers, Dave