st 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
ent 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
ny applications for Carp,
Getopts::Long, File::Find, etc. It is an application specific function.
This slope is slippery.
Alan Gutierrez
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 te
cussing the implementation of a module, lets have
an RFC that frames it that way.
Alan Gutierrez
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
st find to me.
The negation of C< use less 'rolled_loops' >,
C< use more 'unrolled_loops' >, does not sound very weird at all.
Weren't we planning on haveing a use more as an opposite of use less? If
so, let cuteness prevail!
Alan Gutierrez
gnificant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields.
Alan Gutierrez
#x27;t see why this has be implemented in the core in C.
Once again, if core means core modules, and as a part of cgi.pm or
headers.pm or some such I am not concerned. And a switch for tainting
and inclusion of this module sounds peachy. No core.
Alan Gutierrez
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 ',', $
;
> here are some ideas which you can shoot down:
>
Thought I'd add to the list of target ideas that someone else has
already proposed:
file ('/dev/null', 'rwx')
And I agree with Uri that a pragma is the way to go if we are going to
havea all those new function names.
Alan Gutierrez
about pulling some functions from a module
to the core. And for no real good reason. Is query string parsing or
header processing so time consuming that it must be implemented in C?
For any sizeable application input and headers will not be enough.
You'll need cookies and redirection certainly. At which point you will
load CGI.pm anyway (if you are bothering to create this in classic CGI).
Tainting sure. Functions no.
Alan Gutierrez
eat things like add value attributes to inputs based on
the contents of %FDAT.
HTML::Embperl is my favorite embedded perl language, but maybe this
could be pluggable.
Alan Gutierrez
elf = bless ref $class || $class;
public (@$self{qw/ first_name last_name /}) = qw/Alan Gutierrez/;
private (@$self{qw/ weight salary /}) = qw/Err.. *Ahem*/;
laccess (@$self{qw/ age favorite_color /}) = qw/ 28 blue /;
raccess (@$self{qw/ gender eye_color /}) qw / male brown /;
}
14 matches
Mail list logo