Re: [WWdevel] CGI weirdness under Apache 1

[Sam H. <sh...@ma...>]

On Jul 20, 2006, at 6:17 PM, Michael Gage wrote:

> On Jul 20, 2006, at 3:20 PM, Sam Hathaway wrote:
>
>> So you'd think that the solution would be to simply add the "-
>> nosticky" pragma, like we originally tried. However, from looking at
>> the CGI.pm code, I think -nosticky doesn't do what we think it does.
>> What it appears to do is suppress the output of hidden ".cgifields"
>> fields naming each of the radio buttons, checkboxes, and scrolling
>> lists in the form. (And also give the default name ".submit" to
>> unnamed submit buttons.) THAT'S ALL.
>>
>>   As far as i can tell, all that ".cgifields" does is ensures that
>> the parameter *names* for checkboxes, radio buttons, and scrolling
>> lists are still known to CGI.pm even if none of them are selected
>> (and thus don't appear in the request). This has very little to do
>> with form field "stickiness", despite statements to the contrary in
>> the docs. (The only connection is that it prevents checkboxes, radio
>> buttons, and scrolling lists from being reset to their defaults if
>> none of their items are selected.) It looks to me like the only way
>> to turn off form field stickiness is to specify "-override=>1" in
>> each field.
>>
>> This seems really weird to me, since it implies that the CGI module
>> documentation is just plain wrong. Could you do me a favor and look
>> at $NOSTICKY in the CGI.pm source and tell me if I'm missing  
>> something?
>
> I've looked through the code.  As best I can tell you are right.   
> We'll need -overrides
> in nearly all of the CGI::() calls since we assumed that our values  
> wouldn't be overridden
> by values from the param list.  I remember that when we did the CGI  
> scripts for WeBWorK 1.x
> we had a lot of problems of when to use overrides and when they  
> weren't needed.  We were
> probably using GET a good deal more often in that case and actually  
> needed the overrides.
>
> Adding overrides seemed to work.  I added several in my first  
> attempt to analyze the problem.
> I got tired after awhile, but it is not that overwhelming a chore  
> -- just tedious. I think we can
> safely assume that we want -override =>1 in every CGI call with a - 
> name parameter.

I tried attacking this from the other angle -- delete all the params  
from the CGI object before any form field functions can be called.  
This makes all requests (GET and POST) under both versions of Apache  
behave like POST requests under Apache 1. As far as I can tell, this  
is working. Plus, it's a much less invasive solution than  
CGIParamShim or CGIeasytags -- it's pretty much a one-liner in a  
subclass.

I've added it as WeBWorK::CGIDeleteParams. I also added it as an  
alternative in WeBWorK::CGI. It needs additional testing, which I  
will give it as I continue porting efforts.

> I haven't been doing
> lots of testing with the standard CGI -- are you still getting  
> weird behavior a lot of the time?

Yeah, CGIParamShim wasn't really solving the problem. But  
CGIDeleteParams seems to so far.

> We could also decide to go with CGIeasytags.  If the extra {} are  
> bothering you, we can
> be a bit more clever about deciding whether the input to CGI::foo()  
> is of the form:
> (1) CGI::foo({params], text]    -- easy
> (2) CGI::foo(-name=>'foo', value = >'bar') or
> (3) CGI:: foo( "name", "foo", "value", "bar")  i.e.  is supposed to  
> produce namefoovaluebar
> (4)CGI::foo("foo", "bar");
>
> Nothing would be perfect but one could do a lot more than I tried to.

The extra {} are a bit annoying, but what really bugs me about  
CGIeasytags is that you've had to reimplement parts of CGI (and  
CGI::Util) to make it compatible with how we've been calling CGI  
functions.

I just recently discovered the rearrange function in CGI::Util. It  
does most of the parameter munging for the CGI functions, and handles  
all four of the forms you list above. For example, here's the call in  
CGI::hidden:

     my($name,$default,$override,@other) =
	rearrange([NAME,[DEFAULT,VALUE,VALUES],[OVERRIDE,FORCE]],@p);

If you think CGI::EasyTags is the way to go, you might consider  
replacing the parameter parsing with calls to rearrange.
-sam