[Iain, I'd really appreciate it if you'd copy me on your replies to my
posts. The volume is so high that I don't always get time to grovel
through the digests in a timely manner.]
On Sat, 30 Sep 2000, iain truskett wrote:
> * Philip Newton ([EMAIL PROTECTED]) [30 Sep 2000 02:47]:
> > However, th
Bart Lateur <[EMAIL PROTECTED]> writes:
> But anyway: whould this imply that URL- and simple HTML escaping and
> back, will now be available through pack()/unpack()? Just like UUE?
> ;-)
Adding base64 encoding/decoding and quoted-printable would also be useful.
Either that, or taking uuenc
On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian wrote:
>Perl6 make it *easier* to write CGI programs than Perl5.
That is a strange sentence.
But anyway: whould this imply that URL- and simple HTML escaping and
back, will now be available through pack()/unpack()? Just like UUE?
;-)
-
On Sat, 30 Sep 2000, iain truskett wrote:
> * Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:47]:
>
> [...]
> > Pity about Solaris. I wonder if Gerard Richter, HTML::Embperl mainter,
> > has ideas about this?
>
> Does it really matter since it's a textarea? Typically you know which
> fields
* Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:55]:
> On Sat, 30 Sep 2000, iain truskett wrote:
> > Or someone could split CGI.pm up so that there's CGI::FormValues and
> > CGI::HTTPHeaders.
> By jove Mr. Truskett, that sounds like a smashing idea! Could we RFC
> this? Do you think Mr. Sti
On Sat, 30 Sep 2000, iain truskett wrote:
> Or someone could split CGI.pm up so that there's CGI::FormValues and
> CGI::HTTPHeaders.
By jove Mr. Truskett, that sounds like a smashing idea! Could we RFC
this? Do you think Mr. Stien would think us pushy?
IMHO this thread is discussing the impleme
* Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:47]:
[...]
> Pity about Solaris. I wonder if Gerard Richter, HTML::Embperl mainter,
> has ideas about this?
Does it really matter since it's a textarea? Typically you know which
fields are only going to have one value and can just not split th
On Fri, 29 Sep 2000, Robert Mathews wrote:
> Alan Gutierrez wrote:
> > HTML::Embperl stuffs form input into a hash just as proposed here. For
> > multiple values it creates a tab-delimited string. This will not present
> > the above trouble with commas, since when the user, for some odd reason,
>
* Nathan Wiger ([EMAIL PROTECTED]) [29 Sep 2000 02:14]:
> > A future protocol could well require things in order. Hence you're
> > having the output headers in order. Therefore you should have the
> > input ones available in order as well.
> I don't see a reason why an @HTTP ordered and %HTTP uno
On Wed, 27 Sep 2000, iain truskett wrote:
> Is order important for @HEADERS? Would it be better to have %HEADERS
> instead that does such auto-formatting?
>From RFC 2068 HTTP/1.0 - 4.2 Message Headers:
The order in which header fields with differing field names are received
is not significant.
* Philip Newton ([EMAIL PROTECTED]) [30 Sep 2000 02:47]:
> On 28 Sep 2000, at 21:36, iain truskett wrote:
[]
> > It's a case of: if you're going to have the output order, then you
> > should provide for the input to be ordered. *As well as* unordered.
> Sorry, I don't follow your line of reas
Alan Gutierrez wrote:
> HTML::Embperl stuffs form input into a hash just as proposed here. For
> multiple values it creates a tab-delimited string. This will not present
> the above trouble with commas, since when the user, for some odd reason,
> enters "Ann Arbor\tMI", in most browsers the input
On 28 Sep 2000, at 21:36, iain truskett wrote:
> * Philip Newton ([EMAIL PROTECTED]) [28 Sep 2000 21:19]:
> > On 27 Sep 2000, at 23:48, iain truskett wrote:
>
> > > So surely you'd want %HTTP (the input headers) to also be an array
> > > rather than a hash, since they'd be required in order as w
Alan Gutierrez wrote:
>
> This header functionality is application specific and does not belong in
> the core any more than the socket stuff which seems to be on its way
> out. I don't see why this has be implemented in the core in C.
>
> Once again, if core means core modules, and as a part of
On Wed, 27 Sep 2000, Adam Turoff wrote:
> On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote:
> > Ziggy, are you interested in this idea enough (at all?) to stick a note
> > about the 'header' function into the RFC? Or should I RFC it separately?
>
> Adding headers() to the core langua
On Wed, 27 Sep 2000, Nathan Wiger wrote:
> Robert Mathews wrote:
> > How are you going to handle multiple values for the same parameter?
> > With CGI.pm, you can say
> > @values = $q->param("foo");
>
> 2. make it a comma-delimited string:
>
>$name = $CGI{name};
>@name = split ',', $
On Thu, Sep 28, 2000 at 08:06:42AM +0200, H . Merijn Brand wrote:
> On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > This and other RFCs are available on the web at
> > http://dev.perl.org/rfc/
> >
> > =head1 TITLE
> >
> > First-Class CGI Support
>
> Freezing
Nathan Wiger wrote:
> 1. make a listref only for multiple values:
>@name = @{$CGI{name}} if ( ref $CGI{name} eq 'ARRAY' );
Ick. That piece of code is small enough, but it's going to end up
replicating itself everywhere %CGI is accessed. This will be a fruitful
new source of bugs when people
> A future protocol could well require things in order. Hence you're
> having the output headers in order. Therefore you should have the input
> ones available in order as well.
I don't see a reason why an @HTTP ordered and %HTTP unordered couldn't
both be supported.
> I'm thinking a $headers_i
* Philip Newton ([EMAIL PROTECTED]) [28 Sep 2000 21:19]:
> On 27 Sep 2000, at 23:48, iain truskett wrote:
> > So surely you'd want %HTTP (the input headers) to also be an array
> > rather than a hash, since they'd be required in order as well?
> I don't care, because I don't work with this much.
On 27 Sep 2000, at 23:48, iain truskett wrote:
> So surely you'd want %HTTP (the input headers) to also be an array
> rather than a hash, since they'd be required in order as well?
I don't care, because I don't work with this much. And I don't know
whether I'd need to bear in mind the protocol
Adam Turoff wrote:
>
> On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote:
> > Ziggy, are you interested in this idea enough (at all?) to stick a note
> > about the 'header' function into the RFC? Or should I RFC it separately?
>
> Adding headers() to the core language (or a similar pr
On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> First-Class CGI Support
Freezing within two days doesn't leave much space for comments and or
objections does it?
I'
Robert Mathews wrote:
>
> > Parse the CGI GET/POST request, returning CGI variables into %CGI
> > (regardless of the source) in an un-HTTP escaped fashion
>
> How are you going to handle multiple values for the same parameter?
> With CGI.pm, you can say
> @values = $q->param("foo");
>
> Are y
At 07:53 PM 9/27/00 -0700, Nathan Wiger wrote:
>Dan Sugalski wrote:
> >
> > >It might be nice if the result of a calculation was never tainted when the
> > >calculation was in a 'no taint' block.
> >
> > Yerk. No, that's bad. The data is still tainted--the fact that it flowed
> > through a "no tai
Dan Sugalski wrote:
>
> >It might be nice if the result of a calculation was never tainted when the
> >calculation was in a 'no taint' block.
>
> Yerk. No, that's bad. The data is still tainted--the fact that it flowed
> through a "no taint" block doesn't make it any more trustworthy. Tainting
>
At 07:09 PM 9/27/00 -0400, James Mastros wrote:
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
>To: "Nathan Wiger" <[EMAIL PROTECTED]>
>Sent: Wednesday, September 27, 2000 4:08 PM
> > 'no taint' and 'use taint' shouldn't affect whether data is tainted--the
> > rules for that should stay in effect. What
* Nathan Wiger ([EMAIL PROTECTED]) [28 Sep 2000 05:33]:
> Philip Newton wrote:
> > > Is order important for @HEADERS? Would it be better to have
> > > %HEADERS instead that does such auto-formatting?
> >
> > In my opinion, no, for the reasons given before. Hashes are
> > unordered, and if you wan
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "Nathan Wiger" <[EMAIL PROTECTED]>
Sent: Wednesday, September 27, 2000 4:08 PM
> 'no taint' and 'use taint' shouldn't affect whether data is tainted--the
> rules for that should stay in effect. What they should alter instead is
> perl's response to tain
From: "Adam Turoff" <[EMAIL PROTECTED]>
> On Wed, Sep 27, 2000 at 12:09:20PM -0400, James Mastros wrote:
> > Really, I don't see why we can't
> > just have a 'use taint' and 'no taint' pargma.
>
> Because taint mode needs to be turned on REEELY early, like before
> pragmas are compiled.
Umm, perh
> Parse the CGI GET/POST request, returning CGI variables into %CGI
> (regardless of the source) in an un-HTTP escaped fashion
How are you going to handle multiple values for the same parameter?
With CGI.pm, you can say
@values = $q->param("foo");
Are you going to make the values of %CGI list
At 12:52 PM 9/27/00 -0700, Nathan Wiger wrote:
>Dan Sugalski wrote:
> >
> > >Because taint mode needs to be turned on REEELY early, like before
> > >pragmas are compiled.
> >
> > 'no taint' does make sense, though 'use taint' might not except to locally
> > undo 'no taint'.
>
>Actually, from my ta
Dan Sugalski wrote:
>
> >Because taint mode needs to be turned on REEELY early, like before
> >pragmas are compiled.
>
> 'no taint' does make sense, though 'use taint' might not except to locally
> undo 'no taint'.
Actually, from my talks with Larry both on and off-list about this, he
convince
Sounds good. I'll start on my 39th :-{ RFC right now... ;-)
-Nate
Adam Turoff wrote:
>
> On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote:
> > Ziggy, are you interested in this idea enough (at all?) to stick a note
> > about the 'header' function into the RFC? Or should I RFC it sep
At 02:20 PM 9/27/00 -0400, Adam Turoff wrote:
>On Wed, Sep 27, 2000 at 12:09:20PM -0400, James Mastros wrote:
> > Really, I don't see why we can't
> > just have a 'use taint' and 'no taint' pargma.
>
>Because taint mode needs to be turned on REEELY early, like before
>pragmas are compiled.
'no ta
On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote:
> Ziggy, are you interested in this idea enough (at all?) to stick a note
> about the 'header' function into the RFC? Or should I RFC it separately?
Adding headers() to the core language (or a similar pragma that is
automagically invo
Philip Newton wrote:
>
> > Is order important for @HEADERS? Would it be better to have %HEADERS
> > instead that does such auto-formatting?
>
> In my opinion, no, for the reasons given before. Hashes are unordered, and
> if you want to order the keys, you need to know the possibly keys and in
>
On Wed, Sep 27, 2000 at 12:09:20PM -0400, James Mastros wrote:
> Really, I don't see why we can't
> just have a 'use taint' and 'no taint' pargma.
Because taint mode needs to be turned on REEELY early, like before
pragmas are compiled.
Z.
On Wed, Sep 27, 2000 at 07:36:42AM -, Perl6 RFC Librarian wrote:
> Tainting should be able to be turned off, as Tom recommends,
> but only if the user turns on the "absolutely, positively,
> do NOT turn on taint mode" switch.
I can see it now -- C. Really, I don't see why we can't
just have a
* Philip Newton ([EMAIL PROTECTED]) [27 Sep 2000 22:51]:
> On Wed, 27 Sep 2000, iain truskett wrote:
> > Is order important for @HEADERS? Would it be better to have %HEADERS
> > instead that does such auto-formatting?
> In my opinion, no, for the reasons given before. Hashes are unordered,
> and
On Wed, 27 Sep 2000, iain truskett wrote:
> Is order important for @HEADERS? Would it be better to have %HEADERS
> instead that does such auto-formatting?
In my opinion, no, for the reasons given before. Hashes are unordered, and
if you want to order the keys, you need to know the possibly keys
* Perl6 RFC Librarian ([EMAIL PROTECTED]) [27 Sep 2000 18:36]: []
[...]
> When this pragma is loaded, it should replace the print coderef with a
> function that will print out all headers in the @HEADERS queue, print
> out the desired output, and restore the print coderef.
It should also ens
42 matches
Mail list logo
