Re: [cgiapp] Re: concerns with new header_props

[Cees Hek <suppressed>]

Quoting Mark Stosberg <suppressed>:

> >> header_props  - works as is
> >
> > Keeping header_props unchanged sounds like a good idea in order not to 
> > break things.
> 
> I think I prefer to move forward with allow header_props to be called
> multiple times. 
> 
> >> header_add    - add a header of this type to the current list
> >> header_set    - replace the current header of this type
> 
> I don't think we need these when header_props can be called more than
> once. I think we just need "add_cookie" to add additional cookies.

By adding a method that is specific to one HTTP header, we are limiting
ourselves in the flexibility of the API.  I will agree that Set-Cookie is the
only commonly used header that appears multiple times in a Response header.  But
what happens when another header comes out that can appear multiple times?

I had a quick read of the RFC for HTTP 1.1, and it looks like there is already
another header that can appear multiple times.  I have never used it, but the
'Warning' header is part of the RFC and can appear multiple times.

By abstracting the interface to not be specific to Set-Cookie headers, we are
ready for the future where http 1.2 may add additional headers that can be
repeated.  We can be very clear in the docs that the header_add function is only
useful for Cookies at this time, and header_set should be used for all other
headers.

> As an alternative, perhaps we could leave header_props alone, but /just/ 
> add the "add_cookie" function, to cover the most common case.
> 
> Finally, I'll mention the solution that doesn't involve any code
> changes: You can accumulate your headers in your own data structure, and
> pass that to header_props() once at the end.

That is what I do now, and is the main reason why I want the functionality in
CGI::App :)  That method doesn't allow for releasing reusable CGI::App modules
on CPAN, since everyone would have to follow these internal data-structures. 
Hence I think there is a good case for including it in the core CGI::App API.

Cheers,

Cees

---------------------------------------------------------------------
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