Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Add Cheader and Cunheader funtions to core distribution The Cheader function would simply: 1. uc the first letter of each tag token and lc the rest, also converting _'s to -'s automatically 2. Add a colon separating each tag and its value, and exactly one newline after each one 3. Combine list elements into a comma-delimited string 4. Append a singular newline as the last element of the list CGI.pm can do this: print header(expires = '+1M'); # Expire in one month. Seems like the header function described above cannot. Oh well, one can always: use CGI; Alan Gutierrez
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Add Cheader and Cunheader funtions to core distribution The Cheader function would simply: 1. uc the first letter of each tag token and lc the rest, also converting _'s to -'s automatically 2. Add a colon separating each tag and its value, and exactly one newline after each one 3. Combine list elements into a comma-delimited string 4. Append a singular newline as the last element of the list This just in from RFC 2068 HTTP/1.1 - 4.2 Message Headers: The field value may be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. Alan Gutierrez
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
Alan Gutierrez wrote: This just in from RFC 2068 HTTP/1.1 - 4.2 Message Headers: The field value may be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. Yes, similar requirements are in RFC 822, which talks about SMTP headers. The header and unheader function would be able to support them. Let's take up further concerns by addressing the Text::Header module itself; I'll check out your other emails and see what can be integrated. Feel free to email me offline as well. Thanks, Nate
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote:
The Cheader function would work very similarly to CCGI.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 Cheader 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 Cheader 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]
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
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. Yeah, Ziggy already mentioned that offlist. The Cheader 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? Probably; that's what the Text::Header module I wrote as a prototype does. ;-) 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. Actually, it does. Remember, a hash is just a list. unheader just returns an ordered list of the headers. So this: @out = header unheader @in; Will always result in identity because it's actually the same as: @temp = unheader @in; @out = header @temp; It's only once you assign to a hash explicitly that everything gets out of whack. -Nate
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On Fri, 29 Sep 2000, Nathan Wiger wrote: 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. Actually, it does. Remember, a hash is just a list. unheader just returns an ordered list of the headers. So this: @out = header unheader @in; Will always result in identity because it's actually the same as: @temp = unheader @in; @out = header @temp; It's only once you assign to a hash explicitly that everything gets out of whack. D'oh! Yes, of course. For some reason I got carried away with the hash thing. You were doing @out = header (@temp = unheader @in); and I thought you were doing @out = header (%temp = unheader @in); If you just take unheader's output and feed it to header, the order will be the same. Thanks for bearing with me ;) Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Add Cheader and Cunheader funtions to core distribution =head2 Location These are such lightweight functions that their impact on core would be negligible. As such, they could potentially be put directly into it, since they are just formatting functions compliant with open standards. They are lightweight functions so is there an enormous benifit to having them in the core implemented in C? Indeed they are just formatting functions, not primitives. There may be many applications for them, but there are many applications for Carp, Getopts::Long, File::Find, etc. It is an application specific function. This slope is slippery. Alan Gutierrez
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
Perl6 RFC Librarian (Today): =head1 TITLE Add Cheader and Cunheader funtions to core distribution Maintainer: Nathan Wiger [EMAIL PROTECTED] =head1 ABSTRACT !-- snip -- This RFC proposes that Perl include a simple function, Cheader, that can be used to interact with these headers more easily. It is a general-purpose formatting function that does not do any content-specific handling (unlike CCGI.pm's version). It is also proposed that an Cunheader function be included which converts in the opposite direction. While I'm not sure if this belongs in the core or not, I think it's nifty, and I'd like to point out an almost inevitable side effect. Knowing well the nature of Perl hackers, this function will almost certainly be used for non-header tasks such as config files, as the data format used in most plaintext headers is both simple and general. Add comment detection to the parsing, f'rinstance, and this is quite similar to a Java Properties file. Useless comment, probably, but it sprung to mind. ~ j. // "The National Association of Theater Concessionaires // reported that in 1986, 60% of all candy sold in movie // theaters was sold to Roger Ebert." -- D. Letterman
