Hi,
Please find attached a small patch to the PHP mail() function. It adds
two options to php.ini:
- mail_add_cgi_headers: add SERVER_NAME, SCRIPT_NAME and REMOTE_ADDR to
the mail headers before piping it to sendmail with the X-CGI-VAR
prefix),
- mail_custom_headers: specify additionnal, site
Hi,
I'm not sure how to test what I noticed, so I figured I would post this here
and see if any of you could test it and see if I'm correct. When I test this
in a non-PHP environment with malloc(), this does present a problem however,
and when running segfaults randomly appear because of it.
In b
> > The Apache2 debate is more interesting. I am just running up a nice
new
> > AMD64, with SUSE9.1 (no 9.2 disk handy), and the first thing I find
-
> > and which does not bother me at all - ONLY Apache2 in the
distribution.
> > I KNOW all the reasons for feet dragging, and I am doing it myself
o
in conjunction with this patch, i find that in ext/standard/mail.c,
php_mail function doesn't check whether user supplies To in headers.
so, if user uses To in first parameter and another identical To in
headers, this leads into double email sending. is this the expected
behaviour or some workaroun
Hans Zaunere wrote:
That presents somewhat of a chicken-and-egg problem. Production sites
won't be compelled to make a move until PHP recommends it in some way,
or if there is a killer feature that pulls people in, regardless of the
perceived stability.
Right, and they shouldn't. If there is no c
Rasmus Lerdorf wrote:
>
> Hans Zaunere wrote:
> > That presents somewhat of a chicken-and-egg problem.
> > Production sites won't be compelled to make a move until PHP
> > recommends it in some way, or if there is a killer feature
> > that pulls people in, regardless of the perceived stability.
>
Mike Robinson wrote:
Rasmus Lerdorf wrote:
Hans Zaunere wrote:
That presents somewhat of a chicken-and-egg problem.
Production sites won't be compelled to make a move until PHP
recommends it in some way, or if there is a killer feature
that pulls people in, regardless of the perceived stability.
In TSRM/tsrm_virtual_cwd.c around line 594 we have:
#ifdef REALPATH_CACHE
if (ret == 0 && use_realpath && CWDG(realpath_cache_size_limit)) {
realpath_cache_add(orig_path, orig_path_len, state->cwd,
state->cwd_length, t TSRMLS_CC);
}
#endif
As far as I can tell ret can't be anythin
Defined in tsrm_virtual_cwd.h. It's been active for a while.
Andi
At 07:54 PM 12/28/2004 -0500, Rasmus Lerdorf wrote:
In TSRM/tsrm_virtual_cwd.c around line 594 we have:
#ifdef REALPATH_CACHE
if (ret == 0 && use_realpath && CWDG(realpath_cache_size_limit)) {
realpath_cache_add(orig_path
What's defined in tsrm_virtual_cwd.h? ret? How so?
My question was what the ret==0 check was for.
-Rasmus
Andi Gutmans wrote:
Defined in tsrm_virtual_cwd.h. It's been active for a while.
Andi
At 07:54 PM 12/28/2004 -0500, Rasmus Lerdorf wrote:
In TSRM/tsrm_virtual_cwd.c around line 594 we have:
#
Oh, I misunderstood the question. You are right. Seems like it's useless.
I'll look into it and get back to you.
Andi
At 08:20 PM 12/28/2004 -0500, Rasmus Lerdorf wrote:
What's defined in tsrm_virtual_cwd.h? ret? How so?
My question was what the ret==0 check was for.
-Rasmus
Andi Gutmans wrote:
Hi,
Currently activation functions are called in the following order
on request startup:
1. zend_activate()
2. sapi_activate()
3. php_hash_environment()
4. zend_activate_modules()
Is there any good technical reason behind this order? I don't think
it does make much sense because php_hash_environmen
12 matches
Mail list logo
