[cgiapp] concerns with new header_props

["Jesse Erlbaum" <suppressed>]

Hello all --

Cees, Mark, and I are in a conversation regarding changes to the
functionality of header_props() in version 3.2.  Before I reply to Cees'
message, I wanted to forward it to the list to get your input.

-Jesse-


-----Original Message-----
From: Cees Hek [mailto:suppressed 
Sent: Friday, November 07, 2003 9:32 PM
To: Jesse Erlbaum
Cc: 'Mark Stosberg'
Subject: RE: [cgiapp] concerns with new header_props


Quoting Jesse Erlbaum <suppressed>:

> Hi Mark, Cees --
> 
> I think this conversation should go on the list, if you're not
opposed.

I have no problems with this discussion going to the list.

> Regarding the cookie functionality:  I would rather not fix problems
in
> CGI.pm.  That said, how does CGI.pm handle this situation?  If I call
> $query->header(-cookie=>{...}) multiple times does it aggregate your
> cookies?  If not, than it's not a CGI-App problem -- it's a CGI.pm
> problem.

The CGI.pm header() function is a onetime use function.  It doesn't
store the
headers, it will return the requested headers immediately including any
extra
required headers to make up a valid request.  This is not so much a
problem with
CGI.pm as it is more a design decision that made sense in a function
based module.

The existence of the header_props and header_type methods in C::A shows
that it
already had special functions to deal with this 'limitation' of CGI.pm.
This is
because the part of the program that prints the headers is not the same
part of
the program that decides what the headers should contain (ie what the
content-type is, or whether we redirect, or what cookies need to be
set).

I believe that since we already need the ability to cache the headers in
C::A,
we should make it flexible enough to allow the headers to be changed at
multiple
stages of the request.

A good example of the need for this comes from one of the driving forces
behind
CGI::Application, which is to build reusable code.  If someone built a
standard
authentication module for CGI::Application, there is a good chance that
this
code will need to set a cookie.  There is currently no good way to do
this with
CGI::Application, since this code would be required to call header_props
to set
the cookie, but those headers are almost guaranteed to be clobbered by
the rest
of the program (ie when the code decides to set the content type).

A very quick bit of psuedocode to illustrate this:

package My::Base;

use base CGI::Application;

sub cgiapp_prerun {
  my $self = shift;

  # Do the authentication and set a cookie if needed
  if (no cookie yet) {
    $self->header_props(-cookie => $cookie);
  }
}


package My::App;

use base My::Base;

sub cgiapp_prerun {
  my $self = shift;

  # Make sure we run the cgiapp_prerun mode in our parent class
  $self->SUPER::cgiapp_prerun();

  # Turn off caching (will clobber the cookie that was set earlier)
  $self->header_props(-pragma => 'no-cache');
}


sub my_image_runmode {
  my $self = shift;

  # Return an image
  # Change the content type (clobbers the pragma header)
  $self->header_props(-type => 'image/png');

  return \$the_image;
}


I don't see this example as being that unlikely, but it is imposible to
do
without caching the headers somewhere.  The header caching code could be
added
to the My::Base class and then a cgiapp_postrun method could send the
collected
headers to header_props, which will then turn around and pass them to
CGI.pm...
 That just seems like unnecesary complications for such a simple thing.


Now the talk we had about needing a way to handle multiple cookie
headers fits
right in with this problem.  The above example could easily be expanded
to
include 2 locations where cookies need to be set.

Perhaps a change from 'add_cookie($cookie)' to header_add(-cookie =>
$cookie)
and header_set(-cookie => $cookie) would be more palletable.  This would
give
user the ability to overwrite a single header, and also add a header to
the
current list.  That would abstract the interface to not include anything
specific to any given header.

header_props  - works as is
header_add    - add a header of this type to the current list
header_set    - replace the current header of this type

I would suggest that header_add and header_set only accept one header
type, and
then a scalar or arrayref of header values.  This should have zero
impact on
existing code, and would make working with headers much more flexible.
Going
back to the psuedocode above, replacing the calls to header_props with
calls to
header_[set|add] would allow the program to work as expected.

Sorry about the length of this post, but I tend to get a bit verbose
sometimes :)

Cheers,

Cees



> 
> > -----Original Message-----
> > From: Mark Stosberg [mailto:suppressed 
> > Sent: Friday, November 07, 2003 1:43 PM
> > To: Cees Hek
> > Cc: Jesse Erlbaum
> > Subject: Re: [cgiapp] concerns with new header_props
> > 
> > 
> > On Sat, Nov 08, 2003 at 05:10:26AM +1100, Cees Hek wrote:
> > > Quoting Mark Stosberg <suppressed>:
> > > > I think I like the idea of leaving in the 'clobber' 
> > behavior, but adding
> > > > another method that sets an additional cookie. I'm not 
> > sure what to name
> > > > it. Maybe:
> > > > 
> > > >  $self->add_cookie($cookie2);
> > > > 
> > > > That's more intuitive to me than having additional 
> > cookies be added by
> > > > default and then have another function like "reset_cookies".
> > > 
> > > I like that idea.  I'll agree that a "reset_cookies" does 
> > not sound very
> > > intuitive, or useful.
> > > 
> > > One note on the name "add_cookie", I am a big user of 
> > mod_perl, and the
> > > Apache::Cookie module uses the term 'bake' to add a cookie 
> > to the outgoing
> > > headers.  Do you think it worthwhile to pick up on that 
> > term to stay consistent
> > > with existing modules?  Perhaps having an alias to both an 
> > "add_cookie" and
> > > "bake_cookie" method would be a good compromise.
> > > 
> > > So just to reiterate, this is the way I would see the 
> > header_props and
> > > add_cookie methds working together.
> > > 
> > > header_props - maintains a hash of headers, and merges the 
> > results when called
> > > multiple time, clobbering any duplicates.
> > > 
> > > add_cookie - adds a cookie to any existing cookie(s) in the 
> > hash that
> > > header_props maintains.  If header_props is called with a 
> > cookie header after
> > > add_cookie is called, the original cookie(s) will be clobbered.
> > > 
> > > Those two changes would cover all my concerns.  I will 
> > probably have some time
> > > tonight to write a patch that covers these changes, if this 
> > is deemed a
> > > worthwhile addition.
> > 
> > That's exactly what I was thinking as well. You can build on my work
> > that I started here:
> > 
> http://mark.stosberg.com/Tech/perl/CGI-Application-3.2.tar.gz
> 
> CC Jesse when you finish-- he said he was going to review the changes
> this weekend. I'll encourage to you to also add the tests,
documentation
> and "Changes" file entries for your work as well.
> 
> You may notice that I didn't use your patch to fix header_props. I had
> trouble getting it from the mail message I found, so I re-implemented
it
> myself. I still gave you credit in the "Changes" file, though. :)
> 
> You could also make another change that Jesse and I discussed while
you
> are at it: change all occurrences of "run-mode" to "run mode" in the
> documentation (remove the dash). This will make everything more
> consistent. 
> 
> I can take care of what you don't get to.
> 
> Thanks!
> 
> 	Mark
> 
> --
>  . . . . . . . . . . . . . . . . . . . . . . . . . . . 
>    Mark Stosberg            Principal Developer  
>    suppressed     Summersault, LLC     
>    765-939-9301 ext 202     database driven websites
>  . . . . . http://www.summersault.com/ . . . . . . . .
> 
> 
> 
> 






---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed