On 28 Sep 2000, Perl6 RFC Librarian wrote:
> The C<header> function would work very similarly to C<CGI.pm>'s:
>
> @HEADERS = header(content_type => 'text/html',
> author => 'Nathan Wiger',
> last_modified => $date,
> accept => [qw(text/html text/plain)]);
>
> This would produce an array of the following:
>
> @HEADERS = ("Content-Type: text/html\n",
> "Author: Nathan Wiger\n",
> "Last-Modified: Wed Sep 27 13:31:06 PDT 2000\n",
> "Accept: text/html, text/plain\n",
> "\n");
>
> Notice that the last element is a "\n" by itself, providing the
> necessary blank line separating headers and content.
Hm. This makes it difficult to construct a header incrementally -- for
example, @HEADERS=(); push @HEADERS, header(content_type=>'a',
author=>'b'); # 75 lines later; push @HEADERS, header(last_modified=>'c',
accept=>'d');
Since in this case, there would be two "blank" head lines instead of just
one.
> The C<header> function would simply:
>
> 1. uc the first letter of each tag token and lc the rest
Du you want to use the word "ucfirst" here?
> That is, the process that C<header> does is exactly reversed, including
> stripping of trailing newlines, conversion to lowercase, and so forth.
> So, this call:
>
> @out = header unheader @in;
>
> Should result in C<@out> being exactly equivalent to C<@in>.
It cannot, of course, since the order of hash keys obtained by flattening
the hash is not necessarily the same as when you built the hash. So you
might feed in an @in with "Foo: bar" and "Hello: world", unheader it into
a hash, header it back into an array, and get "Hello: world" followed by
"Foo: bar". This may or may not be a problem.
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
