Re: [cgiapp] concerns with new header_props
It looks like the attachment didn't make it through... (I guess there are some bugs in IMP with attachments!). Anyway, I have put the patch at the following URL: http://cees.crtconsulting.ca/perl/patches/CGI-Application-3.1.headers.patch Let me know if anyone has any trouble getting it from there... Cheers, Cees Quoting Cees Hek [EMAIL PROTECTED]: Quoting Jesse Erlbaum [EMAIL PROTECTED]: 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. Since the comments on this thread have been quiet for about a week now, I thought I would write a patch to implement the features we talked about. Perhaps that will trigger some more discussion on what would be the best way to implement any extra features to the header management in C::A. I have added both the header_add and header_set methods. header_props remains as is so as not to alter existing functionality. I have also added several new tests to the test suite to make sure everything works as expected. Comments? Cees - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] concerns with new header_props
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.
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.
I agree with Cees here.
This is not a CGI.pm problem.
CGI::App should provide an interface for setting cookies one by one (
rather than all at once).
Cees gave some very good examples why that is useful.
The same goes for all the other headers.
header_props - works as is
Keeping header_props unchanged sounds like a good idea in order not to
break things.
header_add- add a header of this type to the current list
I think adding a header of this type to the current list makes sense
only for cookies.
Passing a list (arrayref) to CGI-header does not work with other
headers than cookies:
CGI::header(-expires = [1,2], -cookie = [1,2]);
results in
Set-Cookie: 1 === array ref working
(two cookie headers)
Set-Cookie: 2
Expires: ARRAY(0x1a264a0) === array ref not working
Date: Sun, 09 Nov 2003 12:54:25 GMT
Content-Type: text/html; charset=ISO-8859-1
so we could just call the function add_cookie (and it does not take a
type anymore, just a list of cookies).
For maximum compatibility with the many tools people use, the cookies
are passed in as plain strings (with their encoded value).
This precludes us from eliminating duplicate cookies (with the same
name) but if we remember the order in which the cookies are added, that
should be okay (second cookie header wins over first header)
header_set- replace the current header of this type
okay.
Just my two yen,
Thilo
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] concerns with new header_props
Quoting Thilo Planz [EMAIL PROTECTED]: header_add- add a header of this type to the current list I think adding a header of this type to the current list makes sense only for cookies. Passing a list (arrayref) to CGI-header does not work with other headers than cookies: CGI::header(-expires = [1,2], -cookie = [1,2]); results in Set-Cookie: 1 === array ref working (two cookie headers) Set-Cookie: 2 Expires: ARRAY(0x1a264a0) === array ref not working Date: Sun, 09 Nov 2003 12:54:25 GMT Content-Type: text/html; charset=ISO-8859-1 But notice that CGI.pm doesn't die when you do this. It just does what the user has asked. I don't think we should build in a whole bunch of functionality into CGI::App to check the validity of the headers that they are sending in. I think CGI::App should just have a fairly transparent interface to the CGI.pm header functionality. we are still depending on the user to use the correct CGI.pm syntax (ie using -cookie to set a Set-Cookie header, and -type to set a Content-type header). So why should we bother doing checks on the parameters when that is really the job of CGI.pm. I think it will be sufficient to clearly define what header_add and header_set do, and explain that header_add should be used when setting cookies so as not to clobber any existing cookies that may have been set, and all other headers should use header_set. Cheers, Cees - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] concerns with new header_props
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:[EMAIL PROTECTED]
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 [EMAIL PROTECTED]:
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:[EMAIL PROTECTED]
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 [EMAIL PROTECTED]:
I think I like
