[PHP-DEV] Sugestion: Most common errors....(Session Management)

[Ernani Joppert Pontes Martins]

I have a sugestion..

Like some of "a lot" of designers want to use ASP scripts on server side

I have had a lot of critics about session handling on PHP.

Yes I know that you can't send headers to the browser when you've already
sent some other stuffs, but ASP users have strange feeling that this is
weird.

They are not able to understand this procedure, and this way give them some
bad feelings about using PHP.

Can't we implement some procedure that checks if Cookies and session
commands were specified in the wrong way and automatically fix this for the
ASP wrong programmers?

If we found some cookies and session parameters on the entire script, can
php intend to send this values to the browser w/o send that warning message
?

This procedure should minimize most common problems to bring PHP as the most
Strong server side scripting language used in the entire internet.

I am not a ASP fan, I had this problems while I was trying to bring more
people to PHP and quit to implement Microsoft ASP solutions.

Cheers,

Ernani




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] pear's Mail using smtp not working with cvs php

[Jan Schneider]

Zitat von Matt Haught <[EMAIL PROTECTED]>:

> I am trying to use pear's Mail functions to send email to my local smtp
> server (FreeBSD 4.4 using qmail-smtpd), but it sort of gets hung up when
> communicating with the smtp server.  (I also tried a 2nd smtp server with
> the same hang).  It can take many minutes (way over the script's time out
> strangely) of the script just setting there going very slowly before I
> guess
> it finally times out (no errors are given).  Using recordio on the smtp
> server shows what seems to be a very long time for php to respond to the
> output of the server.  The communication that usually takes under a
> second,
> is taking multiple minutes.  I was using an Oct 1st checkout, which
> failed
> so I backed it out a few times (3:00AM EST each day) with fresh copies to
> try to find where the problem was introduced:

I'm seeing this too, and it has nothing to do with Mail_SMTP, not even with
Net_Socket in which case this would be the wrong list anyway.

I _think_ it happened after one of Wez' stream commits, but as I don't
rebuild php daily I can't tell for sure. I guess your detailed list when it
worked and when it failed might help to trap this down to one of the stream
commits (hopefully).

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Sugestion: Most common errors....(Session Management)

[Ernani Joppert Pontes Martins]

Another idea is to provide to more newbie users a PHP Administrator like in
Coldfusion Administrator.

This will also let the remote user change some php directives.

[]'s

Ernani


"Ernani Joppert Pontes Martins" <[EMAIL PROTECTED]> escreveu na
mensagem [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I have a sugestion..
>
> Like some of "a lot" of designers want to use ASP scripts on server
side
>
> I have had a lot of critics about session handling on PHP.
>
> Yes I know that you can't send headers to the browser when you've already
> sent some other stuffs, but ASP users have strange feeling that this is
> weird.
>
> They are not able to understand this procedure, and this way give them
some
> bad feelings about using PHP.
>
> Can't we implement some procedure that checks if Cookies and session
> commands were specified in the wrong way and automatically fix this for
the
> ASP wrong programmers?
>
> If we found some cookies and session parameters on the entire script, can
> php intend to send this values to the browser w/o send that warning
message
> ?
>
> This procedure should minimize most common problems to bring PHP as the
most
> Strong server side scripting language used in the entire internet.
>
> I am not a ASP fan, I had this problems while I was trying to bring more
> people to PHP and quit to implement Microsoft ASP solutions.
>
> Cheers,
>
> Ernani
>
>
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Sugestion: Most common errors....(Session Management)

[Gareth Ardron]

At 05:06 02/10/2002 -0300, you wrote:

>Yes I know that you can't send headers to the browser when you've already
>sent some other stuffs, but ASP users have strange feeling that this is
>weird.

php.ini : Output buffering = On
what is wrong with this?

>Can't we implement some procedure that checks if Cookies and session
>commands were specified in the wrong way and automatically fix this for the
>ASP wrong programmers?

the overhead on this would be *huge*. You're talking about parsing a 
script, editing it and then re-parsing it.
The only way which this could be done without impacting on performance 
would be to enable it only when ASP style open/close tags were used, but 
even then, this'll have an effect on speed for some users.

>This procedure should minimize most common problems to bring PHP as the most
>Strong server side scripting language used in the entire internet.

I'm still failing to see what's bad/wrong about turning on output buffering.

>I am not a ASP fan, I had this problems while I was trying to bring more
>people to PHP and quit to implement Microsoft ASP solutions.

try doing image manipulation in asp, then you'll have a fairly solid reason ;)


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Sugestion: Most common errors....(Session Management)

[Ernani Joppert Pontes Martins]

Hi Gareth,

I do not know about performance impacts

Lke I've said, that is just an idea for ASP guys to see the PHP Power.

If it impacts on performance, let them know

But this will be problem of them, just let them know that if send this
session when it is already sent, the performance will get lower.

Just my 2 cents.

Best Regards,

Ernani


"Gareth Ardron" <[EMAIL PROTECTED]> escreveu na mensagem
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> At 05:06 02/10/2002 -0300, you wrote:
>
> >Yes I know that you can't send headers to the browser when you've already
> >sent some other stuffs, but ASP users have strange feeling that this is
> >weird.
>
> php.ini : Output buffering = On
> what is wrong with this?
>
> >Can't we implement some procedure that checks if Cookies and session
> >commands were specified in the wrong way and automatically fix this for
the
> >ASP wrong programmers?
>
> the overhead on this would be *huge*. You're talking about parsing a
> script, editing it and then re-parsing it.
> The only way which this could be done without impacting on performance
> would be to enable it only when ASP style open/close tags were used, but
> even then, this'll have an effect on speed for some users.
>
> >This procedure should minimize most common problems to bring PHP as the
most
> >Strong server side scripting language used in the entire internet.
>
> I'm still failing to see what's bad/wrong about turning on output
buffering.
>
> >I am not a ASP fan, I had this problems while I was trying to bring more
> >people to PHP and quit to implement Microsoft ASP solutions.
>
> try doing image manipulation in asp, then you'll have a fairly solid
reason ;)
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Sugestion: Most common errors....(Session Management)

[DJ Anubis]

Le Mercredi 2 Octobre 2002 10:06, Ernani Joppert Pontes Martins a écrit :

> Yes I know that you can't send headers to the browser when you've already
> sent some other stuffs, but ASP users have strange feeling that this is
> weird.

That's not a PHP problem, but deals with headers and page standardization. ASP 
users should deal with standards.

> Can't we implement some procedure that checks if Cookies and session
> commands were specified in the wrong way and automatically fix this for the
> ASP wrong programmers?
>
> If we found some cookies and session parameters on the entire script, can
> php intend to send this values to the browser w/o send that warning message
> ?

Sounds like you did not RTFM (Read This Fine Manual) in PHP docs. If you want 
those cookies and other header stuff be transparently manipulated, you can:
1) Enable output buffering in PHP.INI
2) Use direct output buffering functions as discussed in Output Control 
Functions in PHP manual.

When using output buffering, the whole body is buffered and cached while 
headers are set. This is the straight answer to your problem.
But, when you don't want to buffer the page, you have to deal by yourself with 
headers, as no buffering is sending right away whatever is printed to the 
browser.

> This procedure should minimize most common problems to bring PHP as the
> most Strong server side scripting language used in the entire internet.
>
> I am not a ASP fan, I had this problems while I was trying to bring more
> people to PHP and quit to implement Microsoft ASP solutions.

As stated above, this procedure exists, and is there for quite some time now. 
Maybe the biggest problem is developpers not wanting RTFM and imagining PHP 
should be ASP and have the same syntax, the same bugs and [add whatever you 
want]. This is quite the wrong way of thinking, exactly as if you asked C to 
be syntaxically equivalent to Basic.

DJ Anubis.



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Sugestion: Most common errors....(Session Management)

[Gareth Ardron]

At 05:36 02/10/2002 -0300, you wrote:
>Hi Gareth,
>
>I do not know about performance impacts

well, if you're talking about talking a script, "reading it-> editing it -> 
parsing -> executing", it stands to reason that this'll have more overhead 
than just "parse -> execute" and so performance will suffer.
Like I say, this is why there is the option to turn on something like what 
you're proposing in the php.ini file, but it's not enabled by default as it 
does have a performance hit.

>Lke I've said, that is just an idea for ASP guys to see the PHP Power.
>If it impacts on performance, let them know
>But this will be problem of them, just let them know that if send this
>session when it is already sent, the performance will get lower.

but this is why there is the output buffering option in the php.ini 
fileit does exactly what you're asking - it just doesn't assume that 
the programmer is an ASP guy, as most php programmers arn't.
In all seriousness, check out the output buffering option. It's there for a 
reason


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Sugestion: Most common errors....(Session Management)

[Ernani Joppert Pontes Martins]

That's right.

I did not RTFM.
I did not knew about this php.ini directive.
Like I've said, I was used to understand php procedure to handle sessions.

But some of ASP programmers was / is not...

Sorry to bring some lose of time.

[]'s

Ernani



"Dj Anubis" <[EMAIL PROTECTED]> escreveu na mensagem
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Le Mercredi 2 Octobre 2002 10:06, Ernani Joppert Pontes Martins a écrit :

> Yes I know that you can't send headers to the browser when you've already
> sent some other stuffs, but ASP users have strange feeling that this is
> weird.

That's not a PHP problem, but deals with headers and page standardization.
ASP
users should deal with standards.

> Can't we implement some procedure that checks if Cookies and session
> commands were specified in the wrong way and automatically fix this for
the
> ASP wrong programmers?
>
> If we found some cookies and session parameters on the entire script, can
> php intend to send this values to the browser w/o send that warning
message
> ?

Sounds like you did not RTFM (Read This Fine Manual) in PHP docs. If you
want
those cookies and other header stuff be transparently manipulated, you can:
1) Enable output buffering in PHP.INI
2) Use direct output buffering functions as discussed in Output Control
Functions in PHP manual.

When using output buffering, the whole body is buffered and cached while
headers are set. This is the straight answer to your problem.
But, when you don't want to buffer the page, you have to deal by yourself
with
headers, as no buffering is sending right away whatever is printed to the
browser.

> This procedure should minimize most common problems to bring PHP as the
> most Strong server side scripting language used in the entire internet.
>
> I am not a ASP fan, I had this problems while I was trying to bring more
> people to PHP and quit to implement Microsoft ASP solutions.

As stated above, this procedure exists, and is there for quite some time
now.
Maybe the biggest problem is developpers not wanting RTFM and imagining PHP
should be ASP and have the same syntax, the same bugs and [add whatever you
want]. This is quite the wrong way of thinking, exactly as if you asked C to
be syntaxically equivalent to Basic.

DJ Anubis.





-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] REVIEW: Imminent session patch

[Sascha Schumann]

Could some kind soul with a thorough understanding of the
engine details please review the attached patch?

Changes:

- Fix two simple memory leaks.
- Fix a bug which did not initialize $_SESSION, if
  is_array($HTTP_SESSION_VARS) was true.

- Sascha


Index: session.c
===
RCS file: /repository/php4/ext/session/session.c,v
retrieving revision 1.323
diff -u -r1.323 session.c
--- session.c   1 Oct 2002 11:59:45 -   1.323
+++ session.c   2 Oct 2002 09:10:37 -
@@ -258,7 +258,9 @@
if (sym_global == NULL && sym_track == NULL) {
zval *empty_var;
 
-   ALLOC_INIT_ZVAL(empty_var);
+   ALLOC_INIT_ZVAL(empty_var); /* this sets refcount to 1 */
+   ZVAL_DELREF(empty_var); /* our module does not maintain a ref 
+*/
+   /* The next call will increase refcount by NR_OF_SYM_TABLES==2 
+*/
zend_set_hash_symbol(empty_var, name, namelen, 1, 2, 
Z_ARRVAL_P(PS(http_session_vars)), &EG(symbol_table));
} else if (sym_global == NULL) {
zend_set_hash_symbol(*sym_track, name, namelen, 1, 1, 
&EG(symbol_table));
@@ -270,7 +272,7 @@
zval *empty_var;

ALLOC_INIT_ZVAL(empty_var);
-   zend_set_hash_symbol(empty_var, name, namelen, 0, 1, 
Z_ARRVAL_P(PS(http_session_vars)));
+   ZEND_SET_SYMBOL_WITH_LENGTH(Z_ARRVAL_P(PS(http_session_vars)), 
+name, namelen+1, empty_var, 1, 0);
}
}
 }
@@ -465,23 +467,16 @@
 
 static void php_session_track_init(TSRMLS_D)
 {
-   zval **old_vars = NULL;
+   /* Unconditionally destroy existing arrays -- possible dirty data */
+   zend_hash_del(&EG(symbol_table), "HTTP_SESSION_VARS", 
+   sizeof("HTTP_SESSION_VARS"));
+   zend_hash_del(&EG(symbol_table), "_SESSION", sizeof("_SESSION"));
 
-   if (zend_hash_find(&EG(symbol_table), "HTTP_SESSION_VARS", 
sizeof("HTTP_SESSION_VARS"), (void **)&old_vars) == SUCCESS && Z_TYPE_PP(old_vars) == 
IS_ARRAY) {
-   PS(http_session_vars) = *old_vars;
-   zend_hash_clean(Z_ARRVAL_P(PS(http_session_vars)));
-   } else {
-   if(old_vars) {
-   zend_hash_del(&EG(symbol_table), "HTTP_SESSION_VARS", 
sizeof("HTTP_SESSION_VARS"));
-   zend_hash_del(&EG(symbol_table), "_SESSION", 
sizeof("_SESSION"));
-   }
-   MAKE_STD_ZVAL(PS(http_session_vars));
-   array_init(PS(http_session_vars));
-   PS(http_session_vars)->refcount = 2;
-   PS(http_session_vars)->is_ref = 1;
-   zend_hash_update(&EG(symbol_table), "HTTP_SESSION_VARS", 
sizeof("HTTP_SESSION_VARS"), &PS(http_session_vars), sizeof(zval *), NULL);
-   zend_hash_update(&EG(symbol_table), "_SESSION", sizeof("_SESSION"), 
&PS(http_session_vars), sizeof(zval *), NULL);
-   }
+   MAKE_STD_ZVAL(PS(http_session_vars));
+   array_init(PS(http_session_vars));
+   
+   ZEND_SET_GLOBAL_VAR("HTTP_SESSION_VARS", PS(http_session_vars));
+   ZEND_SET_GLOBAL_VAR("_SESSION", PS(http_session_vars));
 }
 
 static char *php_session_encode(int *newlen TSRMLS_DC)


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP_AUTH_USER in 4.3

[David Reid]

This also seems to be a problem for SquirrelMail (2.0.8) which just hangs
after the "upgrade". It was working OK before I changed to CVS.

david

- Original Message -
From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
To: "David Reid" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 02, 2002 1:29 AM
Subject: Re: [PHP-DEV] PHP_AUTH_USER in 4.3


> It shouldn't have stopped working.  Did you change your register_globals
> setting or something?
>
> On Wed, 2 Oct 2002, David Reid wrote:
>
> > Is support for this being dropped or is it just not added yet? Just
changed
> > from 4.2.3 and was surprised to see that it stopped working...
> >
> > david
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/pgsql pgsql.c php_pgsql.h

[Dan Kalowsky]

On Wednesday, October 2, 2002, at 12:10 AM, Yasuo Ohgaki wrote:
> I don't mind to have alias like pg_result_seek() or
> have only pg_result_seek().

I would rather see it named pg_result_seek as it is more consistent 
with what this function accomplishes.  It also opens the door for ODBC 
to follow in these steps a bit more.

 >---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/pgsql pgsql.c php_pgsql.h

[Marcus Börger]

At 13:41 02.10.2002, Dan Kalowsky wrote:
>On Wednesday, October 2, 2002, at 12:10 AM, Yasuo Ohgaki wrote:
>>I don't mind to have alias like pg_result_seek() or
>>have only pg_result_seek().
>
>I would rather see it named pg_result_seek as it is more consistent with 
>what this function accomplishes.  It also opens the door for ODBC to 
>follow in these steps a bit more.


So why not add an alias for the mysql function and use the
preferred name?

marcus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/pgsql pgsql.c php_pgsql.h

[Derick Rethans]

On Wed, 2 Oct 2002, Marcus Börger wrote:

> At 13:41 02.10.2002, Dan Kalowsky wrote:
> >On Wednesday, October 2, 2002, at 12:10 AM, Yasuo Ohgaki wrote:
> >>I don't mind to have alias like pg_result_seek() or
> >>have only pg_result_seek().
> >
> >I would rather see it named pg_result_seek as it is more consistent with 
> >what this function accomplishes.  It also opens the door for ODBC to 
> >follow in these steps a bit more.
> 
> 
> So why not add an alias for the mysql function and use the
> preferred name?

Sounds good to me

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: phpscr

[Jihad BENABRA]

:)

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.3.0

[Sebastian Bergmann]

Andrei Zmievski wrote:
> Once the critical bugs are fixed, I intend to branch the tree in
> preparation for 4.3.0 cycle. The remaining critical bugs are:

  Didn't Zak want to upgrade the bundled libmysql for PHP 4.3.0?

  Zak?

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP_AUTH_USER in 4.3

[Rasmus Lerdorf]

I just checked with current cvs and this simple test script:

Hello $PHP_AUTH_USER.";
echo "You entered $PHP_AUTH_PW as your password.";
  }
?>
This is A TEST

The output after entering the auth data was:

  Hello Rasmus.

  You entered foo as your password.
  This is A TEST

So, it works just fine.

You aren't by any chance using Apache2?

-Rasmus

On Wed, 2 Oct 2002, David Reid wrote:

> This also seems to be a problem for SquirrelMail (2.0.8) which just hangs
> after the "upgrade". It was working OK before I changed to CVS.
>
> david
>
> - Original Message -
> From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
> To: "David Reid" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, October 02, 2002 1:29 AM
> Subject: Re: [PHP-DEV] PHP_AUTH_USER in 4.3
>
>
> > It shouldn't have stopped working.  Did you change your register_globals
> > setting or something?
> >
> > On Wed, 2 Oct 2002, David Reid wrote:
> >
> > > Is support for this being dropped or is it just not added yet? Just
> changed
> > > from 4.2.3 and was surprised to see that it stopped working...
> > >
> > > david
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] getimagetype() broken for jpegs?

[Andrei Zmievski]

On Tue, 01 Oct 2002, Rasmus Lerdorf wrote:
> So result is never filled in as it doesn't think we hit any markers.  Yet
> a "file foo.jpg" returns:
> 
>   foo.jpg: JPEG image data, JFIF standard 1.02, resolution (DPI), 72 x 72
> 
> I have tried it with a number of different jpegs.  My libjpeg is:
> 
>   libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40557000)
> 
> Can someone recreate this in current CVS HEAD?

Nope, it works fine for me.

-Andrei   http://www.gravitonic.com/

Give a man a fish; you have fed him for today.  Teach a man to use
the Net and he won't bother you for weeks.
   -Author unknown

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] getimagetype() broken for jpegs?

[Rasmus Lerdorf]

Hrm...  Actually, after a bit more checking it is only some jpegs that
don't work.  Specifically the ones coming from my digital camera are no
longer working.  Images that used to work with getimagesize() are now not,
so I think something changed.  Try running getimagesize() on this image:

  http://lerdorf.com/azj.jpg

-Rasmus

On Wed, 2 Oct 2002, Andrei Zmievski wrote:

> On Tue, 01 Oct 2002, Rasmus Lerdorf wrote:
> > So result is never filled in as it doesn't think we hit any markers.  Yet
> > a "file foo.jpg" returns:
> >
> >   foo.jpg: JPEG image data, JFIF standard 1.02, resolution (DPI), 72 x 72
> >
> > I have tried it with a number of different jpegs.  My libjpeg is:
> >
> > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40557000)
> >
> > Can someone recreate this in current CVS HEAD?
>
> Nope, it works fine for me.
>
> -Andrei   http://www.gravitonic.com/
>
> Give a man a fish; you have fed him for today.  Teach a man to use
> the Net and he won't bother you for weeks.
>-Author unknown
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP_AUTH_USER in 4.3

[Edin Kadribasic]

Maybe this has to do with a fact that PHP_AUTH_USER will not work
when used with some external apache authentication mechanism in
4.3.0.

Edin

- Original Message -
From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
To: "David Reid" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 02, 2002 3:06 PM
Subject: Re: [PHP-DEV] PHP_AUTH_USER in 4.3


> I just checked with current cvs and this simple test script:
>
>if (!isset($PHP_AUTH_USER)) {
> header('WWW-Authenticate: Basic realm="The Realm"');
> header('HTTP/1.0 401 Unauthorized');
> echo 'Text to send if user hits Cancel button';
> exit;
>   } else {
> echo "Hello $PHP_AUTH_USER.";
> echo "You entered $PHP_AUTH_PW as your password.";
>   }
> ?>
> This is A TEST
>
> The output after entering the auth data was:
>
>   Hello Rasmus.
>
>   You entered foo as your password.
>   This is A TEST
>
> So, it works just fine.
>
> You aren't by any chance using Apache2?
>
> -Rasmus
>
> On Wed, 2 Oct 2002, David Reid wrote:
>
> > This also seems to be a problem for SquirrelMail (2.0.8) which
just hangs
> > after the "upgrade". It was working OK before I changed to CVS.
> >
> > david
> >
> > - Original Message -
> > From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
> > To: "David Reid" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Wednesday, October 02, 2002 1:29 AM
> > Subject: Re: [PHP-DEV] PHP_AUTH_USER in 4.3
> >
> >
> > > It shouldn't have stopped working.  Did you change your
register_globals
> > > setting or something?
> > >
> > > On Wed, 2 Oct 2002, David Reid wrote:
> > >
> > > > Is support for this being dropped or is it just not added
yet? Just
> > changed
> > > > from 4.2.3 and was surprised to see that it stopped
working...
> > > >
> > > > david
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List 
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > >
> > >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] getimagetype() broken for jpegs?

[Andrei Zmievski]

On Wed, 02 Oct 2002, Rasmus Lerdorf wrote:
> Hrm...  Actually, after a bit more checking it is only some jpegs that
> don't work.  Specifically the ones coming from my digital camera are no
> longer working.  Images that used to work with getimagesize() are now not,
> so I think something changed.  Try running getimagesize() on this image:
> 
>   http://lerdorf.com/azj.jpg

Yes, it doesn't work for me either. I don't see anything in image.c that
would have changed, so it must be something in the streams code,
perhaps?

-Andrei   http://www.gravitonic.com/

Commitment, n.:
Commitment can be illustrated by a breakfast of ham and eggs. The chicken
was involved, the pig was committed.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Sebastian Bergmann]

Yasuo Ohgaki wrote:
> yohgaki Mon Sep 30 22:43:33 2002 EDT
>
>   Modified files:
> /php4/main  output.c
>   Log:
>   Fixed implicit flush.

  This commit broke my script, that I mentioned before, again. It now
  dumps the contents of a variable to stdout instead of writing it to a
  file.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] getimagetype() broken for jpegs?

[Marcus Börger]

At 15:42 02.10.2002, Andrei Zmievski wrote:
>On Wed, 02 Oct 2002, Rasmus Lerdorf wrote:
> > Hrm...  Actually, after a bit more checking it is only some jpegs that
> > don't work.  Specifically the ones coming from my digital camera are no
> > longer working.  Images that used to work with getimagesize() are now not,
> > so I think something changed.  Try running getimagesize() on this image:
> >
> >   http://lerdorf.com/azj.jpg
>
>Yes, it doesn't work for me either. I don't see anything in image.c that
>would have changed, so it must be something in the streams code,
>perhaps?


Yes i just checked it. When i replace php_stream_seek() with
php_stream_read() it works.

cvs -z3 -q diff ext\standard\image.c (in directory S:\php4-HEAD\)
Index: ext/standard/image.c
===
RCS file: /repository/php4/ext/standard/image.c,v
retrieving revision 1.69
diff -u -r1.69 image.c
--- ext/standard/image.c18 Sep 2002 20:37:24 -  1.69
+++ ext/standard/image.c2 Oct 2002 14:08:12 -
@@ -398,6 +398,7 @@
 {
 return M_EOI;/* we hit EOF */
 }
+   php_error_docref( NULL TSRMLS_CC, E_NOTICE, 
"Reading:'0x%02X'", marker);
 if ( last_marker==M_COM && comment_correction>0)
 {
 if ( marker != 0xFF)
@@ -436,7 +437,14 @@
 length = length-2;
 if (length)
 {
-   php_stream_seek(stream, (long)length, SEEK_CUR);
+   //php_stream_seek(stream, (long)length, SEEK_CUR);
+   unsigned char a[1];
+
+   while (length) {
+   php_stream_read(stream, a, 1);
+   length--;
+   }
+
 }
  }
  /* }}} */
@@ -483,6 +491,7 @@
 for (;;) {
 marker = php_next_marker(stream, marker, 1, ff_read 
TSRMLS_CC);
 ff_read = 0;
+   php_error_docref( NULL TSRMLS_CC, E_NOTICE, "Marker: 
'0x%02X'", marker);
 switch (marker) {
 case M_SOF0:
 case M_SOF1:



When using this patch you will see all markers:
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xE1'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Marker: '0xE1'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xFF'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xE2'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Marker: '0xE2'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xFF'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xE2'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Marker: '0xE2'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xFF'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xE2'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Marker: '0xE2'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xFF'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xDB'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Marker: '0xDB'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xFF'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xC4'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Marker: '0xC4'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xFF'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xDD'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Marker: '0xDD'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xFF'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Reading:'0xC0'
Command line code(1) : Notice - getimagesize() 
[http://127.0.0.1/phpManual/function.getimagesize.html]: Marker: '0xC0'

Before only the 

Re: [PHP-DEV] getimagetype() broken for jpegs?

[Rasmus Lerdorf]

Just to make sure I am not crazy, I checked 4.2.3.  getimagesize() on that
azj.jpg image returns:

array(6) {
  [0]=>
  int(1536)
  [1]=>
  int(1024)
  [2]=>
  int(2)
  [3]=>
  string(26) "width="1536" height="1024""
  ["bits"]=>
  int(8)
  ["channels"]=>
  int(3)
}

which is correct.  So we definitely do have breakage

The streams related change was:

-   FP_FREAD(temp, sizeof(temp), socketd, fp, issock);
-   FP_FREAD((char*) &dim, sizeof(dim), socketd, fp, issock);
+   php_stream_read(stream, temp, sizeof(temp));
+   php_stream_read(stream, (char*) &dim, sizeof(dim));

-   if((FP_FREAD(a, sizeof(a), socketd, fp, issock)) <= 0) return 0;
+   if((php_stream_read(stream, a, sizeof(a))) <= 0) return 0;

Along with a few more, but they look correct to me, so I don't think the
problem is there.

I am more suspicious of the php_next_marker() changes..  But who knows,
the unified diff of image.c is 958 lines between 4.2.3 and current HEAD.

-Rasmus

On Wed, 2 Oct 2002, Andrei Zmievski wrote:

> On Wed, 02 Oct 2002, Rasmus Lerdorf wrote:
> > Hrm...  Actually, after a bit more checking it is only some jpegs that
> > don't work.  Specifically the ones coming from my digital camera are no
> > longer working.  Images that used to work with getimagesize() are now not,
> > so I think something changed.  Try running getimagesize() on this image:
> >
> >   http://lerdorf.com/azj.jpg
>
> Yes, it doesn't work for me either. I don't see anything in image.c that
> would have changed, so it must be something in the streams code,
> perhaps?
>
> -Andrei   http://www.gravitonic.com/
>
> Commitment, n.:
> Commitment can be illustrated by a breakfast of ham and eggs. The chicken
> was involved, the pig was committed.
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: melvyn

[Melvyn Sopacua]

replacement of [EMAIL PROTECTED], lost credentials

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Marcus Börger]

At 15:45 02.10.2002, Sebastian Bergmann wrote:
>Yasuo Ohgaki wrote:
> > yohgaki Mon Sep 30 22:43:33 2002 EDT
> >
> >   Modified files:
> > /php4/main  output.c
> >   Log:
> >   Fixed implicit flush.
>
>   This commit broke my script, that I mentioned before, again. It now
>   dumps the contents of a variable to stdout instead of writing it to a
>   file.

It also breaks my testcases, too.

marcus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS Account Request: melvyn

[Rasmus Lerdorf]

http://master.php.net/forgot.php

On 2 Oct 2002, Melvyn Sopacua wrote:

> replacement of [EMAIL PROTECTED], lost credentials
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] A survey about handling bugs in open source projects

[Gunes Koru]

Hello all PHP contributors,

I am conducting a survey about the way defects (or bugs-I use these two words
 interchangeably) are handled in open source software projects. It is
very easy to fill out. It consists of three short sections which can be
completed at once or in different sessions. The survey can be found in the
address:

http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html

This survey includes questions that can be answered by developers,testers,
bug fixers, bug database owners, and project managers. I would greatly
appreciate if you could visit the above web page and fill out the survey.
I am sure you will find the questions very interesting and thought
provoking.  We need the help of all contributors of PHP in the above roles
to understand how we can use bugs data collected in your project for
software engineering research.

Nowadays, there is a huge amount of bug data on the Internet collected
during the development of all open source products. A bug database include
useful information to identify high-risk, problem-prone modules
(components) in the software. It is also possible to measure these
problem-prone components using several complexity metrics (McCabe's
cyclomatic complexity, Halstead's metrics, etc.), since the source code is
available. If a characterization, which is generalizable across many
projects (sub-projects) could be made in terms of complexity, focused
quality improvement would become possible in the future projects. So far,
in the literature, there is quite amount of evidence that 80 percent of
the problems occur from 20 percent of the modules (or software
components), which gives hope toward tremendous quality increase, time
savings, and increased success in the open source projects.

Also a bug database includes useful information about the efficiency of
development. For example, if a lot of bugs related to design of the system
are found after release, when coding bugs are expected more, then this may
indicate that the design or architecture of the system was done cursory.
Of course, these kinds of conclusions would require some kind of
classification of bugs according to their insertion time after they get
fixed.

However, before trying to find an answer to the questions like above, our
first step is to understand if the available data is usable for empirical
research purposes. This means having an idea about the consistency of bug
reports and fixes, accuracy of data, completeness of the data, etc. At
this point, we need your help. By filling out this survey, you will help
us understand availability, representativeness, and characteristics of the
data in the bug database of your project.  I'd like to stress that the
purpose of this survey is only and only research. Open source development
gained a very good momentum in the last decade. We hope that outcomes of
our research will help even increase this momentum. We will acknowledge
the help of all supporting communities when mentioning our results.

In addition to these goals, we also think that filling out this short
survey can lead to some immediate brain-storming in individuals and
groups, and exchange of ideas among the PHP community, which will
be useful too. As I said, you will find the survey questions interesting.
If you'd prefer to learn more about our research, I included a link in the
above web page of our survey. This link provides more information about
our research.

Once more, your contribution is very important to us. Please visit

http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html

and fill out our survey.


We greatly appreciate your helps. Please contact me for any question you
might have.

Thanks

-- 
***

A. Gunes Koru

Research Assistant, Ph.D. Student

Southern Methodist University
Computer Science and Engineering Department
6425 North Ownby Drive
Science and Information Building Room 317
Dallas, TX 75205


Home: 214 691 5633
Work: 214 768 2005
Cell: 214 893 7311
http://www.seas.smu.edu/~gkoru
Email: [EMAIL PROTECTED]

***


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] patch to add CURLOPT_FTP_USE_EPSV option to curl extension

[Alex Howansky]

Hello developers,

I'd like to propose this simple patch (against 4.2.3) to the curl extension. It
adds the ability to specify the CURLOPT_FTP_USE_EPSV option via the
curl_setopt() function. (This is the same as the curl command line option
--disable-epsv.)

Regards,

*** ext/curl/curl.c.origTue Oct  1 12:48:52 2002
--- ext/curl/curl.c Tue Oct  1 12:51:18 2002
***
*** 135,140 
--- 135,141 
REGISTER_CURL_CONSTANT(CURLOPT_REFERER);
REGISTER_CURL_CONSTANT(CURLOPT_USERAGENT);
REGISTER_CURL_CONSTANT(CURLOPT_FTPPORT);
+   REGISTER_CURL_CONSTANT(CURLOPT_FTP_USE_EPSV);
REGISTER_CURL_CONSTANT(CURLOPT_LOW_SPEED_LIMIT);
REGISTER_CURL_CONSTANT(CURLOPT_LOW_SPEED_TIME);
REGISTER_CURL_CONSTANT(CURLOPT_RESUME_FROM);
***
*** 637,642 
--- 638,644 
case CURLOPT_PUT:
case CURLOPT_MUTE:
case CURLOPT_TIMEOUT:
+   case CURLOPT_FTP_USE_EPSV:
case CURLOPT_LOW_SPEED_LIMIT:
case CURLOPT_SSLVERSION:
case CURLOPT_LOW_SPEED_TIME:

-- 
Alex Howansky
Wankwood Associates
http://www.wankwood.com/



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS /main output.c

[Marcus Börger]

Hi Sebastian can you verify this with implicit flush on/off.

php -d implicit_flush=On/Off

For the cgi sapi it defaults to Off and for the cli executable it
defaults to On.

marcus

At 17:36 02.10.2002, you wrote:
>helly   Wed Oct  2 11:36:29 2002 EDT
>
>   Modified files:
> /php4   NEWS
> /php4/main  output.c
>   Log:
>   Fix implicit_flush
>
>
>Index: php4/NEWS
>diff -u php4/NEWS:1.1169 php4/NEWS:1.1170
>--- php4/NEWS:1.1169Wed Oct  2 04:14:47 2002
>+++ php4/NEWS   Wed Oct  2 11:36:28 2002
>@@ -5,7 +5,7 @@
>{PREFIX}/bin/php. If you don't disable the CGI binary, it will be
>installed as {PREFIX}/bin/php-cgi.
>  - Fixed bug #17825 (ob_start() chunk size option didn't work well). (Yasuo)
>-- Fixed output buffering implicit flush. (Yasuo)
>+- Fixed output buffering implicit flush. (Yasuo, Marcus)
>  - Added getopt() for parsing command line options and arguments. (Jon)
>  - Added pg_fetch_assoc(), pg_fetch_all(), pg_ping(), pg_meta_data(), 
> pg_convert(),
>pg_insert(), pg_select(), pg_update(), pg_delete(), pg_data_seek() and
>Index: php4/main/output.c
>diff -u php4/main/output.c:1.127 php4/main/output.c:1.128
>--- php4/main/output.c:1.127Wed Oct  2 11:10:11 2002
>+++ php4/main/output.c  Wed Oct  2 11:36:29 2002
>@@ -18,7 +18,7 @@
> +--+
>  */
>
>-/* $Id: output.c,v 1.127 2002/10/02 15:10:11 helly Exp $ */
>+/* $Id: output.c,v 1.128 2002/10/02 15:36:29 helly Exp $ */
>
>  #include "php.h"
>  #include "ext/standard/head.h"
>@@ -595,13 +595,11 @@
> /* If implicit_flush is On, send contents to next buffer and return.
>Both PG() and OG() should be used since we should flush implicitly
>always when implicit_flush is enabled in php.ini */
>-   if (PG(implicit_flush) || OG(implicit_flush)) {
>-   php_end_ob_buffer(1, 1 TSRMLS_CC);
>-   return;
>-   }
>-
>-   if (OG(active_ob_buffer).chunk_size
>-   && OG(active_ob_buffer).text_length >= 
>OG(active_ob_buffer).chunk_size) {
>+   if (PG(implicit_flush) || OG(implicit_flush)
>+   /* Also flush after each chunk if output is chunked */
>+   || (OG(active_ob_buffer).chunk_size
>+   && OG(active_ob_buffer).text_length >= 
>OG(active_ob_buffer).chunk_size)
>+   ) {
> zval *output_handler = OG(active_ob_buffer).output_handler;
>
> if (output_handler) {
>
>
>
>--
>PHP CVS Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] pear's Mail using smtp not working with cvs php

[Matt Haught]

I have made a little test script to see where the hang is occuring instead
of figuring out pear today:

";

echo '>' .fgets($fp, 2048);
$c = getmicrotime();
echo " (Read took " .($c-$b). " seconds)";

echo '< EHLO localhost';
fwrite($fp, "EHLO localhost\r\n");
$d = getmicrotime();
echo " (Write took " .($d-$c). " seconds)";

$numlines = 2;  //number of lines to read
for ($i; $i<$numlines; $i++) {
echo '>' .fgets($fp, 2048);
$e = getmicrotime();
echo " (Read took " .($e-$d). " seconds)";
}
?>

The Results:

Sept 22nd
(Connected in 0.0027800798416138 seconds)
>220 haught.org ESMTP (Read took 0.0082589387893677 seconds)
< EHLO localhost (Write took 0.00019896030426025 seconds)
>250-haught.org (Read took 0.0012670755386353 seconds)
>250-AUTH LOGIN CRAM-MD5 PLAIN (Read took 0.0014160871505737 seconds)

Sept 23rd
(Connected in 0.0024210214614868 seconds)
>220 haught.org ESMTP (Read took 60.012040019035 seconds)
< EHLO localhost (Write took 0.00059795379638672 seconds)
>250-haught.org (Read took 60.009819984436 seconds)
>250-AUTH LOGIN CRAM-MD5 PLAIN (Read took 120.02024698257 seconds)

Oct1st
(Connected in 0.010542035102844 seconds)
>220 haught.org ESMTP (Read took 60.008027911186 seconds)
< EHLO localhost (Write took 0.00064098834991455 seconds)
>250-haught.org (Read took 60.009781002998 seconds)
>250-AUTH LOGIN CRAM-MD5 PLAIN (Read took 120.02020800114 seconds)

It appears that fgets is where the problem is occuring.  Its taking over a
minute.  Can anyone confirm?  I tried a server at mail.wvwc.edu and received
the same sort of results.

--
Matt

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch to add CURLOPT_FTP_USE_EPSV option to curlextension

[Derick Rethans]

Hi,

thanks for your patch, I committed it into CVS.

Derick

On Wed, 2 Oct 2002, Alex Howansky wrote:

> 
> Hello developers,
> 
> I'd like to propose this simple patch (against 4.2.3) to the curl extension. It
> adds the ability to specify the CURLOPT_FTP_USE_EPSV option via the
> curl_setopt() function. (This is the same as the curl command line option
> --disable-epsv.)
> 
> Regards,
> 
> *** ext/curl/curl.c.origTue Oct  1 12:48:52 2002
> --- ext/curl/curl.c Tue Oct  1 12:51:18 2002
> ***
> *** 135,140 
> --- 135,141 
> REGISTER_CURL_CONSTANT(CURLOPT_REFERER);
> REGISTER_CURL_CONSTANT(CURLOPT_USERAGENT);
> REGISTER_CURL_CONSTANT(CURLOPT_FTPPORT);
> +   REGISTER_CURL_CONSTANT(CURLOPT_FTP_USE_EPSV);
> REGISTER_CURL_CONSTANT(CURLOPT_LOW_SPEED_LIMIT);
> REGISTER_CURL_CONSTANT(CURLOPT_LOW_SPEED_TIME);
> REGISTER_CURL_CONSTANT(CURLOPT_RESUME_FROM);
> ***
> *** 637,642 
> --- 638,644 
> case CURLOPT_PUT:
> case CURLOPT_MUTE:
> case CURLOPT_TIMEOUT:
> +   case CURLOPT_FTP_USE_EPSV:
> case CURLOPT_LOW_SPEED_LIMIT:
> case CURLOPT_SSLVERSION:
> case CURLOPT_LOW_SPEED_TIME:
> 
> -- 
> Alex Howansky
> Wankwood Associates
> http://www.wankwood.com/
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] pear's Mail using smtp not working with cvs php

[Jan Schneider]

Zitat von Matt Haught <[EMAIL PROTECTED]>:

> It appears that fgets is where the problem is occuring.  Its taking over
> a
> minute.  Can anyone confirm?  I tried a server at mail.wvwc.edu and
> received
> the same sort of results.

Confirmed.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] getimagetype() broken for jpegs?

[Wez Furlong]

Yep, it's probably the streams code (specifically the seeking that marcus
mentioned).
Also, I think there is now a slight bug with fopen wrappers under win32.

I'm all of a sudden really pushed for time, so I might not be able to fix this
before saturday - if that is the case, I'll make an effort to get it sorted
on saturday.

--Wez.

On 10/02/02, "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote:
> Just to make sure I am not crazy, I checked 4.2.3.  getimagesize() on that
> azj.jpg image returns:
> 
> array(6) {
>   [0]=>
>   int(1536)
>   [1]=>
>   int(1024)
>   [2]=>
>   int(2)
>   [3]=>
>   string(26) "width="1536" height="1024""
>   ["bits"]=>
>   int(8)
>   ["channels"]=>
>   int(3)
> }
> 
> which is correct.  So we definitely do have breakage
> 
> The streams related change was:
> 
> - FP_FREAD(temp, sizeof(temp), socketd, fp, issock);
> - FP_FREAD((char*) &dim, sizeof(dim), socketd, fp, issock);
> + php_stream_read(stream, temp, sizeof(temp));
> + php_stream_read(stream, (char*) &dim, sizeof(dim));
> 
> - if((FP_FREAD(a, sizeof(a), socketd, fp, issock)) <= 0) return 0;
> + if((php_stream_read(stream, a, sizeof(a))) <= 0) return 0;
> 
> Along with a few more, but they look correct to me, so I don't think the
> problem is there.
> 
> I am more suspicious of the php_next_marker() changes..  But who knows,
> the unified diff of image.c is 958 lines between 4.2.3 and current HEAD.
> 
> -Rasmus
> 
> On Wed, 2 Oct 2002, Andrei Zmievski wrote:
> 
> > On Wed, 02 Oct 2002, Rasmus Lerdorf wrote:
> > > Hrm...  Actually, after a bit more checking it is only some jpegs that
> > > don't work.  Specifically the ones coming from my digital camera are no
> > > longer working.  Images that used to work with getimagesize() are now not,
> > > so I think something changed.  Try running getimagesize() on this image:
> > >
> > >   http://lerdorf.com/azj.jpg
> >
> > Yes, it doesn't work for me either. I don't see anything in image.c that
> > would have changed, so it must be something in the streams code,
> > perhaps?
> >
> > -Andrei   http://www.gravitonic.com/
> >
> > Commitment, n.:
> > Commitment can be illustrated by a breakfast of ham and eggs. The chicken
> > was involved, the pig was committed.
> >




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS /main output.c

[Sebastian Bergmann]

Marcus Börger wrote:
> Hi Sebastian can you verify this with implicit flush on/off.
>
> php -d implicit_flush=On/Off

  This is odd:

  Both

php -d implicit_flush=On build --format html-chunked

  and

php -d implicit_flush=Off build --format html-chunked

  work fine, but

php build --format html-chunked

  dumps the contents of the mentioned variable to stdout.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: php/embed (build system changes)

[Thies C. Arntzen]

On Tue, Oct 01, 2002 at 10:38:54PM +0200, Sascha Schumann wrote:
> On Tue, 1 Oct 2002, Andrei Zmievski wrote:
> 
> > On Tue, 01 Oct 2002, Sascha Schumann wrote:
> > > Fortunately, I have some spare time and look forward to
> > > purge some of the cruft which has assembled since the CLI
> > > support was added.  By extending the problem domain, we can
> > > simplify and abstract a number of cases in the build system.
> > > That will be a lot of fun.
> >
> > Does this mean that you want to delay 4.3.0?
> 
> Nope, this is 4.3.1 material.

you mean 4.4? our new rules says to merge only fixes into
a release branch. 

tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: php/embed (build system changes)

[Sascha Schumann]

> you mean 4.4? our new rules says to merge only fixes into
> a release branch.

Will HEAD become 4.4 immediately after 4.3.0 branches off?

I would expect that some work needs to be done to further
stabilize the 4.3 branch.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Ilia A.]

On October 2, 2002 05:13 am, Sascha Schumann wrote:
> Could some kind soul with a thorough understanding of the
> engine details please review the attached patch?
>
> Changes:
>
> - Fix two simple memory leaks.
> - Fix a bug which did not initialize $_SESSION, if
>   is_array($HTTP_SESSION_VARS) was true.
>
> - Sascha

The patch does solve the problems it sets out to fix, most important of which 
in my opinion is the memory leak. There is however another problem, which I 
believe should be addressed. The problem being that session_register() 
function does not work unless the user has register_globals enabled.
This particular problem causes problems for anyone using php software that was 
written before this limitation was added. In fact the sessions tests inside 
ext/session/tests fail for that very reason.
To this affect, I have made a few modifications to the patch written by Sascha 
that address this problem. After the patch is applied, register_session() 
works regardless of whether or not register_globals are enabled or disabled.

Ilia

Index: session.c
===
RCS file: /repository/php4/ext/session/session.c,v
retrieving revision 1.323
diff -u -3 -p -u -r1.323 session.c
--- session.c	1 Oct 2002 11:59:45 -	1.323
+++ session.c	2 Oct 2002 14:48:27 -
@@ -241,6 +241,7 @@ typedef struct {
 void php_add_session_var(char *name, size_t namelen TSRMLS_DC)
 {
 	zval **sym_track = NULL;
+	zval **sym_global = NULL;
 	
 	zend_hash_find(Z_ARRVAL_P(PS(http_session_vars)), name, namelen + 1, 
 			(void *) &sym_track);
@@ -249,29 +250,25 @@ void php_add_session_var(char *name, siz
 	 * Set up a proper reference between $_SESSION["x"] and $x.
 	 */
 
-	if (PG(register_globals)) {
-		zval **sym_global = NULL;
-		
-		zend_hash_find(&EG(symbol_table), name, namelen + 1, 
-(void *) &sym_global);
+	zend_hash_find(&EG(symbol_table), name, namelen + 1, (void *) &sym_global);
 
-		if (sym_global == NULL && sym_track == NULL) {
-			zval *empty_var;
+	if (sym_global == NULL && sym_track == NULL) {
+		zval *empty_var;
 
-			ALLOC_INIT_ZVAL(empty_var);
-			zend_set_hash_symbol(empty_var, name, namelen, 1, 2, Z_ARRVAL_P(PS(http_session_vars)), &EG(symbol_table));
-		} else if (sym_global == NULL) {
-			zend_set_hash_symbol(*sym_track, name, namelen, 1, 1, &EG(symbol_table));
-		} else if (sym_track == NULL) {
-			zend_set_hash_symbol(*sym_global, name, namelen, 1, 1, Z_ARRVAL_P(PS(http_session_vars)));
-		}
-	} else {
-		if (sym_track == NULL) {
-			zval *empty_var;
-	
-			ALLOC_INIT_ZVAL(empty_var);
-			zend_set_hash_symbol(empty_var, name, namelen, 0, 1, Z_ARRVAL_P(PS(http_session_vars)));
-		}
+		ALLOC_INIT_ZVAL(empty_var); /* this sets refcount to 1 */
+		ZVAL_DELREF(empty_var); /* our module does not maintain a ref */
+		/* The next call will increase refcount by NR_OF_SYM_TABLES==2 */
+		if (PG(register_globals)) {
+			zend_set_hash_symbol(empty_var, name, namelen, 1, 2,
+Z_ARRVAL_P(PS(http_session_vars)), &EG(symbol_table));
+		} else {
+			zend_set_hash_symbol(empty_var, name, namelen, 1, 1,
+Z_ARRVAL_P(PS(http_session_vars)));
+		}	
+	} else if (sym_global == NULL) {
+		zend_set_hash_symbol(*sym_track, name, namelen, 1, 1, &EG(symbol_table));
+	} else if (sym_track == NULL) {
+		zend_set_hash_symbol(*sym_global, name, namelen, 1, 1, Z_ARRVAL_P(PS(http_session_vars)));
 	}
 }
 
@@ -465,23 +462,16 @@ break_outer_loop:
 
 static void php_session_track_init(TSRMLS_D)
 {
-	zval **old_vars = NULL;
+	/* Unconditionally destroy existing arrays -- possible dirty data */
+	zend_hash_del(&EG(symbol_table), "HTTP_SESSION_VARS", 
+			sizeof("HTTP_SESSION_VARS"));
+	zend_hash_del(&EG(symbol_table), "_SESSION", sizeof("_SESSION"));
 
-	if (zend_hash_find(&EG(symbol_table), "HTTP_SESSION_VARS", sizeof("HTTP_SESSION_VARS"), (void **)&old_vars) == SUCCESS && Z_TYPE_PP(old_vars) == IS_ARRAY) {
-		PS(http_session_vars) = *old_vars;
-		zend_hash_clean(Z_ARRVAL_P(PS(http_session_vars)));
-	} else {
-		if(old_vars) {
-			zend_hash_del(&EG(symbol_table), "HTTP_SESSION_VARS", sizeof("HTTP_SESSION_VARS"));
-			zend_hash_del(&EG(symbol_table), "_SESSION", sizeof("_SESSION"));
-		}
-		MAKE_STD_ZVAL(PS(http_session_vars));
-		array_init(PS(http_session_vars));
-		PS(http_session_vars)->refcount = 2;
-		PS(http_session_vars)->is_ref = 1;
-		zend_hash_update(&EG(symbol_table), "HTTP_SESSION_VARS", sizeof("HTTP_SESSION_VARS"), &PS(http_session_vars), sizeof(zval *), NULL);
-		zend_hash_update(&EG(symbol_table), "_SESSION", sizeof("_SESSION"), &PS(http_session_vars), sizeof(zval *), NULL);
-	}
+	MAKE_STD_ZVAL(PS(http_session_vars));
+	array_init(PS(http_session_vars));
+		
+	ZEND_SET_GLOBAL_VAR("HTTP_SESSION_VARS", PS(http_session_vars));
+	ZEND_SET_GLOBAL_VAR("_SESSION", PS(http_session_vars));
 }
 
 static char *php_session_encode(int *newlen TSRMLS_DC)



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://w

Re: [PHP-DEV] Re: php/embed (build system changes)

[Andrei Zmievski]

On Wed, 02 Oct 2002, Sascha Schumann wrote:
> Will HEAD become 4.4 immediately after 4.3.0 branches off?
> 
> I would expect that some work needs to be done to further
> stabilize the 4.3 branch.

The rule of thumb is that the 4.3 branch is used only for point
releases.

-Andrei   http://www.gravitonic.com/
* George Orwell was an optimist. *

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Sascha Schumann]

> believe should be addressed. The problem being that session_register()
> function does not work unless the user has register_globals enabled.

I think there is a misunderstanding with regard to how
sessions interact with global variables.

The session extension makes use of globals only, if
register_globals is set.

Your patch creates references between track and global
variables, even if register_globals is not enabled.

Prior to 4.3, the session module did not create any
references upon session_register() in the register_globals=1
case.  This however is necesssary to make get_session_var()
reliably work and avoid any lookups in the global sym table.

Because this behaviour is new, I don't see how existing
applications could break.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Tit \"Black\" Petric]

> (snip).. There is however another problem, which I
> believe should be addressed. The problem being that session_register()
> function does not work unless the user has register_globals enabled.
> This particular problem causes problems for anyone using php software that
was
> written before this limitation was added. In fact the sessions tests
inside
> ext/session/tests fail for that very reason.

correct me if i am wrong, but with $_SESSION you dont even need to have
session_register() anymore, as for the behaviour of session_register(), if
it held up to the latest php version, i dont see any sense of changing its
functionality now, it's a less logical step than to encourage people to use
$_SESSION.

personally i think session_register() should have been removed after the
creation of $_SESSION, but i see the logics in backwards compatibility, but
for the future of php (php5.0.0) maybe some functions like this one should
acctually be removed in favour of $_SESSION addressing.

regards,
black


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Derick Rethans]

On Wed, 2 Oct 2002, Tit "Black" Petric wrote:

> correct me if i am wrong, but with $_SESSION you dont even need to have
> session_register() anymore, as for the behaviour of session_register(), if
> it held up to the latest php version, i dont see any sense of changing its
> functionality now, it's a less logical step than to encourage people to use
> $_SESSION.

There is nothing wrong with encouraging, but that does not mean you can 
break thousands of scripts because it's better to use $_SESSION :)

> 
> personally i think session_register() should have been removed after the
> creation of $_SESSION, but i see the logics in backwards compatibility, but
> for the future of php (php5.0.0) maybe some functions like this one should
> acctually be removed in favour of $_SESSION addressing.

Removing is not an option of course, or can we direct all usesr with 
questions to you? :)

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: flex

[Lenar Lõhmus]

Helping (active development) with ext/xslt extension (sablot backend).



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Ilia A.]

On October 2, 2002 02:31 pm, Sascha Schumann wrote:
> > believe should be addressed. The problem being that session_register()
> > function does not work unless the user has register_globals enabled.
>
> I think there is a misunderstanding with regard to how
> sessions interact with global variables.
>
> The session extension makes use of globals only, if
> register_globals is set.
>
> Your patch creates references between track and global
> variables, even if register_globals is not enabled.

> Prior to 4.3, the session module did not create any
> references upon session_register() in the register_globals=1
> case.  This however is necesssary to make get_session_var()
> reliably work and avoid any lookups in the global sym table.
>
> Because this behaviour is new, I don't see how existing
> applications could break.

Its very simply really, as you well know, since PHP 4.2.0 register_globals are 
off by default. Because they are off, session_register does not retrieve a 
value from the variable and only creates a null variable inside the session. 
So, unless the user is aware of this issue and knows that to fix the problem 
they need to enable register globals, which somewhat of a security risk, the 
application they are trying to use won't work. Session is a fairly popular 
extension, it is used by many PHP applications, so this is rather serious 
problem.
My patch does not force the association between track and global variables all 
the time, it is conditional on register_globals being enabled. This does not 
prevent the user from having $test0 & $_SESSION['test0'] as 2 seperate 
varaibles containing unrelated data. 

Ilia

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS Account Request: flex

[Melvyn Sopacua]

FWIW:

Discussion about the future of ext/xslt has started on the Sablotron 
Mailinglist.
Ginger Alliance is providing help and additional resources.

Lenar has been posting several fixes already, which missed 4.2.3 release 
(are currently
in HEAD).


At 18:57 10/2/2002 +, Lenar Lõhmus wrote:

>Helping (active development) with ext/xslt extension (sablot backend).
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php

Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua

<@Logan> I spent a minute looking at my own code by accident.
<@Logan> I was thinking "What the hell is this guy doing?"


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Sessions: Problem with dot's in session names

[Bernhard Fuerst]

Hi,

I got non-working session when using session names like 
BLAH_www.ile.tu-freiberg.de. Did I missed something in thr manual or is 
there something bad in PHP-dev?

cu
Bernhard
-- 
The WTC Conspiracy LIV: "Hail Bush!"
http://www.heise.de/tp/deutsch/special/wtc/13291/1.html
Bilder zum Ansehen: http://www.asiascope.de/


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Mac 8.6 Web Server with PHP

[Bernhard Fuerst]

On Montag, Oktober 6, 2092, at 03:06  Uhr, J Abbott wrote:

> anyone know of a mac 8.6 compatible web server with PHP capibility?

Only one I know of: http://www.tenon.com/products/webten/

cu
Bernhard
-- 
The WTC Conspiracy LIV: "Hail Bush!"
http://www.heise.de/tp/deutsch/special/wtc/13291/1.html
Bilder zum Ansehen: http://www.asiascope.de/


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC: ext/xslt

[Melvyn Sopacua]

All,

as said in my previous message, discussion and efforts to get a solid 
maintenance
for the xslt extension has started on the Sablotron mailinglist, after 
Sterling's announcement.

There are currently two main issues that are pending:

Is it realistic to expect that other xslt processors will be integrated via 
the abstraction,
that Sterling has provided?

If not - this would raise whether the xslt_ namespace is correct (academic 
but still) and if so,
how would (Sablotron) processor specific functions be integrated? Would 
these register under:
xslt_sablot_* or would function xslt_*, which is only available for 
processor X, be a userland
issue, where xslt_backend() would provide the means to detect availibility?

The SXP interface in the Sablotron library provides DOM functions, which 
also allows creation
of DOM documents. Exposing those, would effectively create 2 extensions 
with equal functionality
and totally different approaches (ext/domxml and ext/xslt). Is this 
something we would want in
core (ereg vs. preg / recode vs. iconv / shm vs. shmop)?


Thread on sablotron list:
http://archive.gingerall.cz/archives/public/sablot2002/msg01713.html

Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua

<@Logan> I spent a minute looking at my own code by accident.
<@Logan> I was thinking "What the hell is this guy doing?"


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Sascha Schumann]

> Its very simply really, as you well know, since PHP 4.2.0 register_globals are
> off by default. Because they are off, session_register does not retrieve a
> value from the variable and only creates a null variable inside the session.
> So, unless the user is aware of this issue and knows that to fix the problem
> they need to enable register globals, which somewhat of a security risk, the
> application they are trying to use won't work. Session is a fairly popular
> extension, it is used by many PHP applications, so this is rather serious
> problem.

You fail to see that an application is either designed to
work with enabled register_globals, or it is not.  There is
little in between.  If an application's session part fails
because of register_globals, the rest of the application
which handles input data will also fail.

No magic code in the session extension will cure the support
hassle created by the register_globals change.

The main goal is to have a stable session extension with
little to no behavioral changes from 4.2 to 4.3.  Please keep
that in mind.

> My patch does not force the association between track and global variables all
> the time, it is conditional on register_globals being enabled. This does not
> prevent the user from having $test0 & $_SESSION['test0'] as 2 seperate
> varaibles containing unrelated data.

That's incorrect.  Consider this code with your patch applied
and register_globals=0:

$c = "bla";
session_register("c");
// $_SESSION["c"] is now a ref to $c
$_SESSION["c"] = "other stuff";
// voila, you now have changed the global variable $c

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Ilia A.]

On October 2, 2002 03:46 pm, Sascha Schumann wrote:
> > Its very simply really, as you well know, since PHP 4.2.0
> > register_globals are off by default. Because they are off,
> > session_register does not retrieve a value from the variable and only
> > creates a null variable inside the session. So, unless the user is aware
> > of this issue and knows that to fix the problem they need to enable
> > register globals, which somewhat of a security risk, the application they
> > are trying to use won't work. Session is a fairly popular extension, it
> > is used by many PHP applications, so this is rather serious problem.
>
> You fail to see that an application is either designed to
> work with enabled register_globals, or it is not.  There is
> little in between.  If an application's session part fails
> because of register_globals, the rest of the application
> which handles input data will also fail.
>
> No magic code in the session extension will cure the support
> hassle created by the register_globals change.
>
> The main goal is to have a stable session extension with
> little to no behavioral changes from 4.2 to 4.3.  Please keep
> that in mind.

In this case, would it not be prudent to either depreciate the 
session_register() function or add an E_NOTICE message in the event it is 
used on a system with session_register() disabled?
That way we can atleast provide the users some idea as to why their code is 
not working and perphaps make the 1st step towards eliminating 
session_register() completely at some point in the future.

> > My patch does not force the association between track and global
> > variables all the time, it is conditional on register_globals being
> > enabled. This does not prevent the user from having $test0 &
> > $_SESSION['test0'] as 2 seperate varaibles containing unrelated data.
>
> That's incorrect.  Consider this code with your patch applied
> and register_globals=0:
>
> $c = "bla";
> session_register("c");
> // $_SESSION["c"] is now a ref to $c
> $_SESSION["c"] = "other stuff";
> // voila, you now have changed the global variable $c

That is quite correct. Of course it can be avoided by some additional hacking 
to the code. However, based on your defenition of the goals for the session 
extension, I believe it would be quite useless.

Ilia

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] pear's Mail using smtp not working with cvs php

[Wez Furlong]

On 02/10/02, "Matt Haught" <[EMAIL PROTECTED]> wrote:
> >250-haught.org (Read took 60.009819984436 seconds)

> It appears that fgets is where the problem is occuring.  Its taking over a
> minute.  Can anyone confirm?  I tried a server at mail.wvwc.edu and received
> the same sort of results.

The problem is that fgets is trying to be efficient by reading up the
maximum chunk size (defaults to 8192 bytes) on one go and then looking
for newlines.

As a workaround for anyone experiencing this problem, until I get a chance
to correct it, you can lower the timeout from 60 seconds using the new
default_socket_timeout ini option.

Thanks for your detailed report!

--Wez.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: RFC: ext/xslt

[Sterling Hughes]

> All,
> 
> as said in my previous message, discussion and efforts to get a solid 
> maintenance
> for the xslt extension has started on the Sablotron mailinglist, after 
> Sterling's announcement.
> 
> There are currently two main issues that are pending:
> 
> Is it realistic to expect that other xslt processors will be integrated via 
> the abstraction,
> that Sterling has provided?
> 
> If not - this would raise whether the xslt_ namespace is correct (academic 
> but still) and if so,
> how would (Sablotron) processor specific functions be integrated? Would 
> these register under:
> xslt_sablot_* or would function xslt_*, which is only available for 
> processor X, be a userland
> issue, where xslt_backend() would provide the means to detect availibility?
> 
> The SXP interface in the Sablotron library provides DOM functions, which 
> also allows creation
> of DOM documents. Exposing those, would effectively create 2 extensions 
> with equal functionality
> and totally different approaches (ext/domxml and ext/xslt). Is this 
> something we would want in
> core (ereg vs. preg / recode vs. iconv / shm vs. shmop)?
> 
> 
> Thread on sablotron list:
> http://archive.gingerall.cz/archives/public/sablot2002/msg01713.html


http://www.bumblebury.com/phptodo/xmsl.html

my thoughts on the matter... If you really want to handle XML, XSLT and
the like in PHP, the solution is to build a standardized, documented,
DOM, SAX, XPath, XInclude, XPointer interface, and then have functions
which wrap around these to apply XSLT transformations.  Xalan/Xerces,
Sablotron/Expat, and Libxslt/Libxml all provide, or aim to provide good
support for these things.  Libxml/Libxslt seem to be the most developed
at this point, so I'd suggest bundling them and then working on a
unified extension based on them...

Just my 2c, not really interested in taking the project further...

-Sterling


> 
> Met vriendelijke groeten / With kind regards,
> 
> Webmaster IDG.nl
> Melvyn Sopacua
> 
> <@Logan> I spent a minute looking at my own code by accident.
> <@Logan> I was thinking "What the hell is this guy doing?"
> 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: alrehawi_

[Ali Saif Alrehawi]

Translating the documentation

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Rasmus Lerdorf]

I really don't see why would want to deprecate session_register().
Regardless of whether register_globals is on or off, code like this works
fine:

Set a session var:
  session_register('a');
  $a=1;

Get a session var:
  session_start();
  $a = $_SESSION['a'];

This makes perfect sense to me and I see no reason to change that way of
writing session code.

-Rasmus


On Wed, 2 Oct 2002, Ilia A. wrote:

> On October 2, 2002 03:46 pm, Sascha Schumann wrote:
> > > Its very simply really, as you well know, since PHP 4.2.0
> > > register_globals are off by default. Because they are off,
> > > session_register does not retrieve a value from the variable and only
> > > creates a null variable inside the session. So, unless the user is aware
> > > of this issue and knows that to fix the problem they need to enable
> > > register globals, which somewhat of a security risk, the application they
> > > are trying to use won't work. Session is a fairly popular extension, it
> > > is used by many PHP applications, so this is rather serious problem.
> >
> > You fail to see that an application is either designed to
> > work with enabled register_globals, or it is not.  There is
> > little in between.  If an application's session part fails
> > because of register_globals, the rest of the application
> > which handles input data will also fail.
> >
> > No magic code in the session extension will cure the support
> > hassle created by the register_globals change.
> >
> > The main goal is to have a stable session extension with
> > little to no behavioral changes from 4.2 to 4.3.  Please keep
> > that in mind.
>
> In this case, would it not be prudent to either depreciate the
> session_register() function or add an E_NOTICE message in the event it is
> used on a system with session_register() disabled?
> That way we can atleast provide the users some idea as to why their code is
> not working and perphaps make the 1st step towards eliminating
> session_register() completely at some point in the future.
>
> > > My patch does not force the association between track and global
> > > variables all the time, it is conditional on register_globals being
> > > enabled. This does not prevent the user from having $test0 &
> > > $_SESSION['test0'] as 2 seperate varaibles containing unrelated data.
> >
> > That's incorrect.  Consider this code with your patch applied
> > and register_globals=0:
> >
> > $c = "bla";
> > session_register("c");
> > // $_SESSION["c"] is now a ref to $c
> > $_SESSION["c"] = "other stuff";
> > // voila, you now have changed the global variable $c
>
> That is quite correct. Of course it can be avoided by some additional hacking
> to the code. However, based on your defenition of the goals for the session
> extension, I believe it would be quite useless.
>
> Ilia
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Ilia A.]

On October 2, 2002 04:26 pm, Rasmus Lerdorf wrote:
> I really don't see why would want to deprecate session_register().
> Regardless of whether register_globals is on or off, code like this works
> fine:
>
> Set a session var:
>   session_register('a');
>   $a=1;

That example only works when register_globals are on. When they are off, it 
produces:
var_dump($a) -> int(1)
var_dump($_SESSION['a']) -> NULL

If register globals are enabled, then this example results in:
var_dump($a) -> int(1)
var_dump($_SESSION['a']) -> int(1)

When register_globals are off register_session('a') merely creates a NULL 
entry 'a' entry inside http_session_vars. Since that is the case, would it 
not be simpler to use:

$_SESSION['a'] = &$a;
$a=1;

or

$a = 1;
$_SESSION['a'] = $a;

which work fine regardless of whether register_globals are on or off.

Ilia

> Get a session var:
>   session_start();
>   $a = $_SESSION['a'];
>
> This makes perfect sense to me and I see no reason to change that way of
> writing session code.
>
> -Rasmus
>
> On Wed, 2 Oct 2002, Ilia A. wrote:
> > On October 2, 2002 03:46 pm, Sascha Schumann wrote:
> > > > Its very simply really, as you well know, since PHP 4.2.0
> > > > register_globals are off by default. Because they are off,
> > > > session_register does not retrieve a value from the variable and only
> > > > creates a null variable inside the session. So, unless the user is
> > > > aware of this issue and knows that to fix the problem they need to
> > > > enable register globals, which somewhat of a security risk, the
> > > > application they are trying to use won't work. Session is a fairly
> > > > popular extension, it is used by many PHP applications, so this is
> > > > rather serious problem.
> > >
> > > You fail to see that an application is either designed to
> > > work with enabled register_globals, or it is not.  There is
> > > little in between.  If an application's session part fails
> > > because of register_globals, the rest of the application
> > > which handles input data will also fail.
> > >
> > > No magic code in the session extension will cure the support
> > > hassle created by the register_globals change.
> > >
> > > The main goal is to have a stable session extension with
> > > little to no behavioral changes from 4.2 to 4.3.  Please keep
> > > that in mind.
> >
> > In this case, would it not be prudent to either depreciate the
> > session_register() function or add an E_NOTICE message in the event it is
> > used on a system with session_register() disabled?
> > That way we can atleast provide the users some idea as to why their code
> > is not working and perphaps make the 1st step towards eliminating
> > session_register() completely at some point in the future.
> >
> > > > My patch does not force the association between track and global
> > > > variables all the time, it is conditional on register_globals being
> > > > enabled. This does not prevent the user from having $test0 &
> > > > $_SESSION['test0'] as 2 seperate varaibles containing unrelated data.
> > >
> > > That's incorrect.  Consider this code with your patch applied
> > > and register_globals=0:
> > >
> > > $c = "bla";
> > > session_register("c");
> > > // $_SESSION["c"] is now a ref to $c
> > > $_SESSION["c"] = "other stuff";
> > > // voila, you now have changed the global variable $c
> >
> > That is quite correct. Of course it can be avoided by some additional
> > hacking to the code. However, based on your defenition of the goals for
> > the session extension, I believe it would be quite useless.
> >
> > Ilia
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] --disable-cgi

[Andrei Zmievski]

I'd like to have this patch committed, any comments?

http://www.zend.com/lists/php-dev/200203/msg00407.html

-Andrei   http://www.gravitonic.com/

"C combines all the power of assembly language with
 all the ease of use of assembly language" -- trad

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] --disable-cgi

[Derick Rethans]

On Wed, 2 Oct 2002, Andrei Zmievski wrote:

> I'd like to have this patch committed, any comments?
> 
>   http://www.zend.com/lists/php-dev/200203/msg00407.html

I would like this kind of functionality.

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Apache 2

[Ilia A.]

The attached patch accomplished the following things:

-   Added apache_response_headers(), apache_note(), 
apache_getenv(), apache_setenv() functions.
-   The getallheaders() is renamed to apache_request_headers() 
and an getallheaders() is aliased to it. This makes the code 
similar to existing PHP's Apache 1.X code.
-   Added a better error reporting mechanism to apache_lookup_uri() & virtual()
that provides the user with more detailed error messages in the same 
manner PHP s Apache 1.X code does.

If there are no objections to the patch, I would like to commit to CVS, so 
that the PHP 4.3.0 (whenever it comes out) support of Apache 2.X is slightly 
more complete.

Ilia

Index: php_functions.c
===
RCS file: /repository/php4/sapi/apache2filter/php_functions.c,v
retrieving revision 1.27
diff -u -3 -p -r1.27 php_functions.c
--- php_functions.c	21 Sep 2002 01:53:15 -	1.27
+++ php_functions.c	2 Oct 2002 20:46:58 -
@@ -35,36 +35,47 @@
 
 #include "php_apache.h"
 
-static request_rec *php_apache_lookup_uri(INTERNAL_FUNCTION_PARAMETERS)
+static request_rec *php_apache_lookup_uri(char *filename)
 {
-	zval **p1;
 	php_struct *ctx;
 	
-	if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &p1) == FAILURE)
+	if (!filename) {
 		return NULL;
-
-	convert_to_string_ex(p1);
-
+	}
+	
 	ctx = SG(server_context);
-	return ap_sub_req_lookup_uri(Z_STRVAL_PP(p1), ctx->f->r, ctx->f->next);
+	return ap_sub_req_lookup_uri(filename, ctx->f->r, ctx->f->next);
 }
 
 /* {{{ proto bool virtual(string uri)
  Perform an apache sub-request */
 PHP_FUNCTION(virtual)
 {
+	zval **filename;
 	request_rec *rr;
 
-	rr = php_apache_lookup_uri(INTERNAL_FUNCTION_PARAM_PASSTHRU);
-
-	if (!rr)
+	if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &filename) == FAILURE) {
 		WRONG_PARAM_COUNT;
+	}
+
+	convert_to_string_ex(filename);
+	
+	if (!(rr = php_apache_lookup_uri(Z_STRVAL_PP(filename {
+		php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unable to include '%s' - URI lookup failed", Z_STRVAL_PP(filename));
+		RETURN_FALSE;
+	}
 	
 	if (rr->status == HTTP_OK) {
-		ap_run_sub_req(rr);
+		if (ap_run_sub_req(rr)) {
+			php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unable to include '%s' - request execution failed", Z_STRVAL_PP(filename));
+			ap_destroy_sub_req(rr);
+			RETURN_FALSE;
+		}
 		ap_destroy_sub_req(rr);
 		RETURN_TRUE;
 	}
+	
+	php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unable to include '%s' - error finding URI", Z_STRVAL_PP(filename));
 	ap_destroy_sub_req(rr);
 	RETURN_FALSE;
 }
@@ -79,10 +90,18 @@ PHP_FUNCTION(virtual)
 PHP_FUNCTION(apache_lookup_uri)
 {
 	request_rec *rr;
+	zval **filename;
 
-	rr = php_apache_lookup_uri(INTERNAL_FUNCTION_PARAM_PASSTHRU);
-	if (!rr)
+	if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &filename) == FAILURE) {
 		WRONG_PARAM_COUNT;
+	}
+
+	convert_to_string_ex(filename);
+	
+	if (!(rr = php_apache_lookup_uri(Z_STRVAL_PP(filename {
+		php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unable to include '%s' - URI lookup failed", Z_STRVAL_PP(filename));
+		RETURN_FALSE;
+	}
 	
 	if (rr->status == HTTP_OK) {
 		object_init(return_value);
@@ -117,13 +136,15 @@ PHP_FUNCTION(apache_lookup_uri)
 		ap_destroy_sub_req(rr);
 		return;
 	}
+	
+	php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unable to include '%s' - error finding URI", Z_STRVAL_PP(filename));
 	ap_destroy_sub_req(rr);
 	RETURN_FALSE;
 }
 
 /* {{{ proto array getallheaders(void)
Fetch all HTTP request headers */
-PHP_FUNCTION(getallheaders)
+PHP_FUNCTION(apache_request_headers)
 {
 	php_struct *ctx;
 	const apr_array_header_t *arr;
@@ -143,6 +164,125 @@ PHP_FUNCTION(getallheaders)
 }
 /* }}} */
 
+/* {{{ proto array apache_response_headers(void)
+   Fetch all HTTP response headers */
+PHP_FUNCTION(apache_response_headers)
+{
+	php_struct *ctx;
+	const apr_array_header_t *arr;
+	char *key, *val;
+
+	if (array_init(return_value) == FAILURE) {
+		RETURN_FALSE;
+	}
+	
+	ctx = SG(server_context);
+	arr = apr_table_elts(ctx->f->r->headers_out);
+
+	APR_ARRAY_FOREACH_OPEN(arr, key, val)
+		if (!val) val = empty_string;
+		add_assoc_string(return_value, key, val, 1);
+	APR_ARRAY_FOREACH_CLOSE()
+}
+/* }}} */
+
+/* {{{ proto string apache_note(string note_name [, string note_value])
+   Get and set Apache request notes */
+PHP_FUNCTION(apache_note)
+{
+	php_struct *ctx;
+	zval **note_name, **note_val;
+	char *old_note_val=NULL;
+	int arg_count = ZEND_NUM_ARGS();
+
+	if (arg_count<1 || arg_count>2 ||
+		zend_get_parameters_ex(arg_count, ¬e_name, ¬e_val) == FAILURE) {
+		WRONG_PARAM_COUNT;
+	}
+	
+	ctx = SG(server_context);
+	
+	convert_to_string_ex(note_name);
+
+	old_note_val = (char *) apr_table_get(ctx->r->notes, Z_STRVAL_PP(note_name));
+	
+	if (arg_count == 2) {
+		convert_to_string_ex(note_val);
+		apr_table_set(ctx->r->notes, Z_STRVAL_PP(note_name), Z_STRVAL_PP(note_val));
+	}
+
+	if (old_note_val) {
+		RETURN_STRING

Re: [PHP-DEV] REVIEW: Imminent session patch

[Sascha Schumann]

On Wed, 2 Oct 2002, Rasmus Lerdorf wrote:

> I really don't see why would want to deprecate session_register().
> Regardless of whether register_globals is on or off, code like this works
> fine:
>
> Set a session var:
>   session_register('a');
>   $a=1;
>
> Get a session var:
>   session_start();
>   $a = $_SESSION['a'];

Uh, how ugly.  This has never been supported intentionally.
Looks like a result of multiple people modifying code and not
talking to each other.

Note that the docs for session_register are out of date.  It
is supposed to mean "register a slot in the session domain".
The global variable scope is only included in that domain, if
register_globals is enabled.

> This makes perfect sense to me and I see no reason to change that way of
> writing session code.

I've verified that this works in the 4.2 tree.  I'll update
the patch to include a change to get_session_var.  Sigh.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Rasmus Lerdorf]

> On Wed, 2 Oct 2002, Rasmus Lerdorf wrote:
>
> > I really don't see why would want to deprecate session_register().
> > Regardless of whether register_globals is on or off, code like this works
> > fine:
> >
> > Set a session var:
> >   session_register('a');
> >   $a=1;
> >
> > Get a session var:
> >   session_start();
> >   $a = $_SESSION['a'];
>
> Uh, how ugly.  This has never been supported intentionally.
> Looks like a result of multiple people modifying code and not
> talking to each other.
>
> Note that the docs for session_register are out of date.  It
> is supposed to mean "register a slot in the session domain".
> The global variable scope is only included in that domain, if
> register_globals is enabled.

But that is a bit of a twist of what "register_globals" is supposed to
mean.  As far as I am concerned register_globals only affects how data is
imported into PHP.  Having that flag trigger other behaviours is
completely undocumented and outside the scope of the original intent of
register_globals.  You are effectively overloading register_globals.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Rasmus Lerdorf]

> That example only works when register_globals are on. When they are off, it

Up until 4.3 it worked just fine.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Apache 2

[Edin Kadribasic]

On Wednesday 02 October 2002 23:25, Ilia A. wrote:
> The attached patch accomplished the following things:
>
> - Added apache_response_headers(), apache_note(),
>   apache_getenv(), apache_setenv() functions.
> - The getallheaders() is renamed to apache_request_headers()
>   and an getallheaders() is aliased to it. This makes the code
>   similar to existing PHP's Apache 1.X code.
> - Added a better error reporting mechanism to apache_lookup_uri() &
> virtual() that provides the user with more detailed error messages in the
> same manner PHP s Apache 1.X code does.
>
> If there are no objections to the patch, I would like to commit to CVS, so
> that the PHP 4.3.0 (whenever it comes out) support of Apache 2.X is
> slightly more complete.

Excellent. I was really missing apache_note() for extended logging.

Edin

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Andrei Zmievski]

On Wed, 02 Oct 2002, Sascha Schumann wrote:
> Uh, how ugly.  This has never been supported intentionally.
> Looks like a result of multiple people modifying code and not
> talking to each other.
> 
> Note that the docs for session_register are out of date.  It
> is supposed to mean "register a slot in the session domain".
> The global variable scope is only included in that domain, if
> register_globals is enabled.

Makes sense to me.

-Andrei   http://www.gravitonic.com/

Documentation is worth it just to be able
to answer all your mail with 'RTFM'. -- Alan Cox

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Sascha Schumann]

> But that is a bit of a twist of what "register_globals" is supposed to
> mean.  As far as I am concerned register_globals only affects how data is
> imported into PHP.  Having that flag trigger other behaviours is
> completely undocumented and outside the scope of the original intent of
> register_globals.  You are effectively overloading register_globals.

Nope, it is not.

 If track_vars is enabled and register_globals  is disabled,
 only members of the global associative array
 $HTTP_SESSION_VARS can be registered as session variables.
 The restored session variables will only be available in the
 array $HTTP_SESSION_VARS.

http://de.php.net/manual/en/ref.session.php

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Rasmus Lerdorf]

Hrm, but that documentation is very out of date and didn't match the code
even when it was written.

On Wed, 2 Oct 2002, Sascha Schumann wrote:

> > But that is a bit of a twist of what "register_globals" is supposed to
> > mean.  As far as I am concerned register_globals only affects how data is
> > imported into PHP.  Having that flag trigger other behaviours is
> > completely undocumented and outside the scope of the original intent of
> > register_globals.  You are effectively overloading register_globals.
>
> Nope, it is not.
>
>  If track_vars is enabled and register_globals  is disabled,
>  only members of the global associative array
>  $HTTP_SESSION_VARS can be registered as session variables.
>  The restored session variables will only be available in the
>  array $HTTP_SESSION_VARS.
>
> http://de.php.net/manual/en/ref.session.php
>
> - Sascha
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Sascha Schumann]

On Wed, 2 Oct 2002, Rasmus Lerdorf wrote:

> > That example only works when register_globals are on. When they are off, it
>
> Up until 4.3 it worked just fine.

Yes, there were a series of modification with regard to
$_SESSION which -- modified some of the behaviour.

get_session_var falls back to EG(symbol_table) in 4.2, if a
slot has not been found in $_SESSION.  So, your example works
in 4.2 although it really should not.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Sascha Schumann]

On Wed, 2 Oct 2002, Rasmus Lerdorf wrote:

> Hrm, but that documentation is very out of date and didn't match the code
> even when it was written.

Huh, excuse me, would you please leave that judgement to the
authors of the code and the documentation (Andrei and me).

The documentation is correct in stating that only track_vars
($_SESSION is a track var) are used, if track_vars is on (it
is by default on today) and if register_globals is off.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Rasmus Lerdorf]

On Wed, 2 Oct 2002, Sascha Schumann wrote:

> On Wed, 2 Oct 2002, Rasmus Lerdorf wrote:
>
> > Hrm, but that documentation is very out of date and didn't match the code
> > even when it was written.
>
> Huh, excuse me, would you please leave that judgement to the
> authors of the code and the documentation (Andrei and me).
>
> The documentation is correct in stating that only track_vars
> ($_SESSION is a track var) are used, if track_vars is on (it
> is by default on today) and if register_globals is off.

I am assuming this documentation was not written recently since it talks
about track_vars and there is no way to turn off track_vars today.  And
since it isn't new and the code up until now did not enforce the
restriction of only using track vars, then I don't see how you can say
that this documentation was ever an accurate reflection of what the code
actually did.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: --disable-cgi

[nicos]

It looks fine, nice work.

--

Nicos - CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com - Hébergement de sites Internet

"Andrei Zmievski" <[EMAIL PROTECTED]> a écrit dans le message de news:
[EMAIL PROTECTED]
> I'd like to have this patch committed, any comments?
>
> http://www.zend.com/lists/php-dev/200203/msg00407.html
>
> -Andrei   http://www.gravitonic.com/
>
> "C combines all the power of assembly language with
>  all the ease of use of assembly language" -- trad



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Sascha Schumann]

> I am assuming this documentation was not written recently since it talks
> about track_vars and there is no way to turn off track_vars today.  And

You are right -- it was not written recently.  The semantics
of the session module have not changed since then though.  If
a bug temporarily made something possible which should not
have been, well, that is bad luck.

I'm still considering bug compatibility with 4.2, if readding
that behaviour is not too difficult or introduces other bugs.

> since it isn't new and the code up until now did not enforce the
> restriction of only using track vars, then I don't see how you can say
> that this documentation was ever an accurate reflection of what the code
> actually did.

This bug/feature we are talking about does not work since
this commit and has been killed further by successive commits.

revision 1.81
date: 2002/08/15 21:44:44;  author: zeev;  state: Exp; lines: +19 -9
Make unset($_SESSION['foo']) actually remove the variable from the session,
if register_globals is off.

Now, please choose which bug you prefer -- from my point of
view, a symmetric way of accessing session variables is the
way to go.  The documentation has always stated that for
register_globals=off you would need to use $HTTP_SESSION_VARS
(or $_SESSION), respectively.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Rasmus Lerdorf]

> > I am assuming this documentation was not written recently since it talks
> > about track_vars and there is no way to turn off track_vars today.  And
>
> You are right -- it was not written recently.  The semantics
> of the session module have not changed since then though.  If
> a bug temporarily made something possible which should not
> have been, well, that is bad luck.
>
> I'm still considering bug compatibility with 4.2, if readding
> that behaviour is not too difficult or introduces other bugs.

Are you sure it was only 4.2?  I seem to remember seeing similar code in
4.1.

My main concern here is breaking BC.  Code that worked in 4.2 and likely
earlier versions as well will now break.  If we do decide to break this
code, and that may be the right decision, we need to be very clear about
what we are breaking and shout it from the rooftops in the release
announcement.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REVIEW: Imminent session patch

[Sascha Schumann]

> Are you sure it was only 4.2?  I seem to remember seeing similar code in
> 4.1.

Possibly.  We changed the serialization strategy which is
appealing because of its simplicity, but it is not backwards
compatible.

I'll commit my changes so far (the patch I posted earlier),
tag the session extension and then will try to revert the
serialization strategy and everything associated with it.
The logic needs to be tweaked a bit to make
unset($_SESSION[..]) work.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] TSRM patch for BeOS

[David Reid]

Any chance of committing this patch. Adds support for beos threading to TSRM
and some small corrections for virtual_cwd.

Thanks.

david

Using port 2401
Index: TSRM/TSRM.c
===
RCS file: /repository/TSRM/TSRM.c,v
retrieving revision 1.44
diff -u -r1.44 TSRM.c
--- TSRM/TSRM.c 7 Aug 2002 14:47:05 - 1.44
+++ TSRM/TSRM.c 2 Oct 2002 23:57:12 -
@@ -95,9 +95,10 @@
 static int tls_key;
 #elif defined(TSRM_WIN32)
 static DWORD tls_key;
+#elif defined(BETHREADS)
+static int32 tls_key;
 #endif

-
 /* Startup TSRM (call once for the entire process) */
 TSRM_API int tsrm_startup(int expected_threads, int expected_resources, int
debug_level, char *debug_filename)
 {
@@ -110,6 +111,8 @@
  st_key_create(&tls_key, 0);
 #elif defined(TSRM_WIN32)
  tls_key = TlsAlloc();
+#elif defined(BETHREADS)
+tls_key = tls_allocate();
 #endif

  tsrm_error_file = stderr;
@@ -258,6 +261,8 @@
  st_thread_setspecific(tls_key, (void *) *thread_resources_ptr);
 #elif defined(TSRM_WIN32)
  TlsSetValue(tls_key, (void *) *thread_resources_ptr);
+#elif defined(BETHREADS)
+tls_set(tls_key, (void*) *thread_resources_ptr);
 #endif

  if (tsrm_new_thread_begin_handler) {
@@ -297,6 +302,8 @@
   thread_resources = st_thread_getspecific(tls_key);
 #elif defined(TSRM_WIN32)
   thread_resources = TlsGetValue(tls_key);
+#elif defined(BETHREADS)
+thread_resources = (tsrm_tls_entry*)tls_get(tls_key);
 #else
   thread_resources = NULL;
 #endif
@@ -423,6 +430,8 @@
  return PIThread_getCurrent();
 #elif defined(TSRM_ST)
  return st_thread_self();
+#elif defined(BETHREADS)
+ return find_thread(NULL);
 #endif
 }

@@ -454,6 +463,10 @@
  mutexp = PIPlatform_allocLocalMutex();
 #elif defined(TSRM_ST)
  mutexp = st_mutex_new();
+#elif defined(BETHREADS)
+ mutexp = (beos_ben*)malloc(sizeof(beos_ben));
+ mutexp->ben = 0;
+ mutexp->sem = create_sem(1, "PHP sempahore");
 #endif
 #ifdef THR_DEBUG
   printf("Mutex created thread: %d\n",mythreadid());
@@ -481,6 +494,9 @@
   PISync_delete(mutexp);
 #elif defined(TSRM_ST)
   st_mutex_destroy(mutexp);
+#elif defined(BETHREADS)
+  delete_sem(mutexp->sem);
+  free(mutexp);
 #endif
 }
 #ifdef THR_DEBUG
@@ -508,6 +524,10 @@
  return PISync_lock(mutexp);
 #elif defined(TSRM_ST)
  return st_mutex_lock(mutexp);
+#elif defined(BETHREADS)
+ if (atomic_add(&mutexp->ben, 1) != 0)
+ return acquire_sem(mutexp->sem);
+return 0;
 #endif
 }

@@ -531,6 +551,10 @@
  return PISync_unlock(mutexp);
 #elif defined(TSRM_ST)
  return st_mutex_unlock(mutexp);
+#elif defined(BETHREADS)
+if (atomic_add(&mutexp->ben, -1) != 1)
+ return release_sem(mutexp->sem);
+ return 0;
 #endif
 }

Index: TSRM/TSRM.h
===
RCS file: /repository/TSRM/TSRM.h,v
retrieving revision 1.35
diff -u -r1.35 TSRM.h
--- TSRM/TSRM.h 7 Aug 2002 14:47:05 - 1.35
+++ TSRM/TSRM.h 2 Oct 2002 23:57:12 -
@@ -47,6 +47,9 @@
 # include 
 #elif defined(TSRM_ST)
 # include 
+#elif defined(BETHREADS)
+#include 
+#include 
 #endif

 typedef int ts_rsrc_id;
@@ -73,6 +76,13 @@
 #elif defined(TSRM_ST)
 # define THREAD_T st_thread_t
 # define MUTEX_T st_mutex_t
+#elif defined(BETHREADS)
+# define THREAD_T thread_id
+typedef struct {
+  sem_id sem;
+  int32 ben;
+} beos_ben;
+# define MUTEX_T beos_ben *
 #endif

 typedef void (*ts_allocate_ctor)(void *, void ***);
Index: TSRM/threads.m4
===
RCS file: /repository/TSRM/threads.m4,v
retrieving revision 1.11
diff -u -r1.11 threads.m4
--- TSRM/threads.m4 19 Sep 2001 09:01:05 - 1.11
+++ TSRM/threads.m4 2 Oct 2002 23:57:12 -
@@ -102,26 +102,31 @@
 dnl
 AC_DEFUN(PTHREADS_CHECK,[

-save_CFLAGS=$CFLAGS
-save_LIBS=$LIBS
-PTHREADS_ASSIGN_VARS
-PTHREADS_CHECK_COMPILE
-LIBS=$save_LIBS
-CFLAGS=$save_CFLAGS
+if test "$beos_threads" = "1"; then
+  pthreads_working="yes"
+  ac_cv_pthreads_cflags=""
+else
+  save_CFLAGS=$CFLAGS
+  save_LIBS=$LIBS
+  PTHREADS_ASSIGN_VARS
+  PTHREADS_CHECK_COMPILE
+  LIBS=$save_LIBS
+  CFLAGS=$save_CFLAGS

-AC_CACHE_CHECK(for pthreads_cflags,ac_cv_pthreads_cflags,[
-ac_cv_pthreads_cflags=
-if test "$pthreads_working" != "yes"; then
-  for flag
in -kthread -pthread -pthreads -mthreads -Kthread -threads -mt -qthreaded;
do
-ac_save=$CFLAGS
-CFLAGS="$CFLAGS $flag"
-PTHREADS_CHECK_COMPILE
-CFLAGS=$ac_save
-if test "$pthreads_working" = "yes"; then
-  ac_cv_pthreads_cflags=$flag
-  break
-fi
-  done
+  AC_CACHE_CHECK(for pthreads_cflags,ac_cv_pthreads_cflags,[
+  ac_cv_pthreads_cflags=
+  if test "$pthreads_working" != "yes"; then
+for flag
in -kthread -pthread -pthreads -mthreads -Kthread -threads -mt -qthreaded;
do
+  ac_save=$CFLAGS
+  CFLAGS="$CFLAGS $flag"
+  PTHREADS_CHECK_COMPILE
+  CFLAGS=$ac_save
+  if test "$pthreads_working" = "yes"; then
+ac_cv_pthreads_cflags=$flag
+break
+  fi
+done
+  fi
 fi
 ])

Index: 

[PHP-DEV] apache2filter error...

[David Reid]

This is a new error I just started seeing...

/boot/home/php4/sapi/apache2filter/php_functions.c: In function
`php_apache_lookup_uri':
/boot/home/php4/sapi/apache2filter/php_functions.c:46: error: `tsrm_ls'
undeclared (first use in this function)
/boot/home/php4/sapi/apache2filter/php_functions.c:46: error: (Each
undeclared identifier is reported only once
/boot/home/php4/sapi/apache2filter/php_functions.c:46: error: for each
function it appears in.)

Any ideas?

david


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] apache2filter error...

[Ilia A.]

On October 2, 2002 08:30 pm, David Reid wrote:
> This is a new error I just started seeing...
>
> /boot/home/php4/sapi/apache2filter/php_functions.c: In function
> `php_apache_lookup_uri':
> /boot/home/php4/sapi/apache2filter/php_functions.c:46: error: `tsrm_ls'
> undeclared (first use in this function)
> /boot/home/php4/sapi/apache2filter/php_functions.c:46: error: (Each
> undeclared identifier is reported only once
> /boot/home/php4/sapi/apache2filter/php_functions.c:46: error: for each
> function it appears in.)
>
> Any ideas?

Are you using the latest CVS, also which OS is this on?

Ilia

>
> david


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Sessions: Problem with dot's in session names

[Yasuo Ohgaki]

I think I've documented what chars are allowed.
If not, report missing description for allowed char as
session name.

--
Yasuo Ohgaki

Bernhard Fuerst wrote:
> Hi,
> 
> I got non-working session when using session names like 
> BLAH_www.ile.tu-freiberg.de. Did I missed something in thr manual or is 
> there something bad in PHP-dev?
> 
> cu
> Bernhard


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 /ext/pgsql pgsql.c php_pgsql.h

[Yasuo Ohgaki]

Ok. I'll add alias to mysql and rename pgsql function.

--
Yasuo Ohgaki

Derick Rethans wrote:
> On Wed, 2 Oct 2002, Marcus Börger wrote:
> 
> 
>>At 13:41 02.10.2002, Dan Kalowsky wrote:
>>
>>>On Wednesday, October 2, 2002, at 12:10 AM, Yasuo Ohgaki wrote:
>>>
I don't mind to have alias like pg_result_seek() or
have only pg_result_seek().
>>>
>>>I would rather see it named pg_result_seek as it is more consistent with 
>>>what this function accomplishes.  It also opens the door for ODBC to 
>>>follow in these steps a bit more.
>>
>>
>>So why not add an alias for the mysql function and use the
>>preferred name?
> 
> 
> Sounds good to me
> 
> Derick
> 
> --
> 
> ---
>  Derick Rethans   http://derickrethans.nl/ 
>  JDI Media Solutions
> --[ if you hold a unix shell to your ear, do you hear the c? ]-
> 
> 
> 



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Sebastian Bergmann wrote:
> Yasuo Ohgaki wrote:
> 
>>yohgaki Mon Sep 30 22:43:33 2002 EDT
>>
>>  Modified files:
>>/php4/main  output.c
>>  Log:
>>  Fixed implicit flush.
> 
> 
>   This commit broke my script, that I mentioned before, again. It now
>   dumps the contents of a variable to stdout instead of writing it to a
>   file.
> 

A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
crush with deleting wrong buffer with implicit flush. The fix
disabled implicit flush.

I finally fixed implicit flush. Users should worry about
implicit flush directive in php.ini now. e.g. implicit_flush=Off
for normal use.

Apparently, CLI SAPI implicitly enable implicit flush at
initialization no matter what the php.ini setting is. CLI behavior
is wrong, since there is no way to change implicit flush directive
once script is started. I notified this to Edin and he would address
this issue soon hopefully.

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Yasuo Ohgaki wrote:
> A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
> crush with deleting wrong buffer with implicit flush. The fix
> disabled implicit flush.
> 
> I finally fixed implicit flush. Users should worry about
> implicit flush directive in php.ini now. e.g. implicit_flush=Off
> for normal use.

Implicit_flush is changeable SYSTEM or PER_DIR.
If it is enabled, PHP will _always_ flush implicitly.

ob_implicit_flush() uses output_globals, so it can be changed
in anywhere in script. However, ob_implict_flush() cannot turn off
implicit_flush set in php.ini. It works independently.

--
Yasuo Ohgaki




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Alan Knowles]

Yasuo Ohgaki wrote:

> Sebastian Bergmann wrote:
>
>> Yasuo Ohgaki wrote:
>>
>>> yohgaki Mon Sep 30 22:43:33 2002 EDT
>>>
>>>  Modified files:
>>>/php4/main  output.c
>>>  Log:
>>>  Fixed implicit flush.
>>
>>
>>
>>   This commit broke my script, that I mentioned before, again. It now
>>   dumps the contents of a variable to stdout instead of writing it to a
>>   file.
>>
>
> A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
> crush with deleting wrong buffer with implicit flush. The fix
> disabled implicit flush.
>
> I finally fixed implicit flush. Users should worry about
> implicit flush directive in php.ini now. e.g. implicit_flush=Off
> for normal use.
>
> Apparently, CLI SAPI implicitly enable implicit flush at
> initialization no matter what the php.ini setting is. CLI behavior
> is wrong, since there is no way to change implicit flush directive
> once script is started. I notified this to Edin and he would address
> this issue soon hopefully. 

Is it worth adding a note to the output control page
http://www.php.net/manual/en/ref.outcontrol.php and/or ob_start to say
"Note: When upgrading from PHP 4.1 (& 4.2) to 4.3 that due to a bug in 
earlier versions you must ensure that implict_flush is OFF in your 
php.ini, otherwise any output withing ob_start, will be not be hidden 
from output"

or something similar?
(at least it will be documented, even if nobody reads it :)

Regards
Alan

>
>
> -- 
> Yasuo Ohgaki
>
>




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Yasuo Ohgaki]

Alan Knowles wrote:
> Yasuo Ohgaki wrote:
>> A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
>> crush with deleting wrong buffer with implicit flush. The fix
>> disabled implicit flush.
>>
>> I finally fixed implicit flush. Users should worry about
>> implicit flush directive in php.ini now. e.g. implicit_flush=Off
>> for normal use.
>>
>> Apparently, CLI SAPI implicitly enable implicit flush at
>> initialization no matter what the php.ini setting is. CLI behavior
>> is wrong, since there is no way to change implicit flush directive
>> once script is started. I notified this to Edin and he would address
>> this issue soon hopefully. 
> 
> 
> Is it worth adding a note to the output control page
> http://www.php.net/manual/en/ref.outcontrol.php and/or ob_start to say
> "Note: When upgrading from PHP 4.1 (& 4.2) to 4.3 that due to a bug in 
> earlier versions you must ensure that implict_flush is OFF in your 
> php.ini, otherwise any output withing ob_start, will be not be hidden 
> from output"
> 
> or something similar?
> (at least it will be documented, even if nobody reads it :)
> 

Done :)

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: cvs: php4 /ext/standard string.c /ext/standard/tests/strings002.phpt

[Yasuo Ohgaki]

Andrey Hristov wrote:
> andreyWed Oct  2 14:58:10 2002 EDT
> 
>   Added files: 
> /php4/ext/standard/tests/strings  002.phpt 
> 
>   Modified files:  
> /php4/ext/standardstring.c 
>   Log:
>   Making strrchr() binary safe.
>   Test case added.

Some users may be surprised by these.
NEWS entry?

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: cvs: php4 /main output.c

[Yasuo Ohgaki]

Hmm. function w/o PHPAPI is used in var.c
I'll commit new patch soon.

--
Yasuo Ohgaki


Yasuo Ohgaki wrote:
> yohgaki   Wed Oct  2 22:55:19 2002 EDT
> 
>   Modified files:  
> /php4/mainoutput.c 
>   Log:
>   Made some functions inline.
>   Added static for unexported functions.
>   
>   
> Index: php4/main/output.c
> diff -u php4/main/output.c:1.129 php4/main/output.c:1.130
> --- php4/main/output.c:1.129  Wed Oct  2 21:36:44 2002
> +++ php4/main/output.cWed Oct  2 22:55:19 2002
> @@ -18,7 +18,7 @@
> +--+
>  */
>  
> -/* $Id: output.c,v 1.129 2002/10/03 01:36:44 yohgaki Exp $ */
> +/* $Id: output.c,v 1.130 2002/10/03 02:55:19 yohgaki Exp $ */
>  
>  #include "php.h"
>  #include "ext/standard/head.h"
> @@ -45,7 +45,7 @@
>  php_output_globals output_globals;
>  #endif
>  
> -static int php_default_output_func(const char *str, uint str_len TSRMLS_DC)
> +static inline int php_default_output_func(const char *str, uint str_len TSRMLS_DC)
>  {
>   fwrite(str, 1, str_len, stderr);
>   return str_len;
> @@ -579,7 +579,7 @@
>  
>  /* {{{ php_ob_append
>   */
> -static void php_ob_append(const char *text, uint text_length TSRMLS_DC)
> +static inline void php_ob_append(const char *text, uint text_length TSRMLS_DC)
>  {
>   char *target;
>   int original_ob_text_length;
> @@ -612,7 +612,7 @@
>  /* }}} */
>  
>  #if 0
> -static void php_ob_prepend(const char *text, uint text_length)
> +static inline void php_ob_prepend(const char *text, uint text_length)
>  {
>   char *p, *start;
>   TSRMLS_FETCH();
> @@ -635,7 +635,7 @@
>  
>  /* {{{ php_ob_get_buffer
>   * Return the current output buffer */
> -int php_ob_get_buffer(zval *p TSRMLS_DC)
> +static int php_ob_get_buffer(zval *p TSRMLS_DC)
>  {
>   if (OG(ob_nesting_level)==0) {
>   return FAILURE;
> @@ -647,7 +647,7 @@
>  
>  /* {{{ php_ob_get_length
>   * Return the size of the current output buffer */
> -int php_ob_get_length(zval *p TSRMLS_DC)
> +static int php_ob_get_length(zval *p TSRMLS_DC)
>  {
>   if (OG(ob_nesting_level) == 0) {
>   return FAILURE;
> 
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: fernandoc

[Fernando Conceição]

I would like make part in group of translators of documentation to pt_BR

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ini_set("register_globals", 1);

[Sascha Schumann]

The session test scripts need to set register_globals -- does
anyone see a problem with making that option setable in the
script?

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main output.c

[Derick Rethans]

On Thu, 3 Oct 2002, Yasuo Ohgaki wrote:

> A little history. When 4.1.0 (or 4.2.0?) is released, I've fixed
> crush with deleting wrong buffer with implicit flush. The fix
> disabled implicit flush.
> 
> I finally fixed implicit flush. Users should worry about
> implicit flush directive in php.ini now. e.g. implicit_flush=Off
> for normal use.
> 
> Apparently, CLI SAPI implicitly enable implicit flush at
> initialization no matter what the php.ini setting is. CLI behavior
> is wrong, since there is no way to change implicit flush directive
> once script is started. I notified this to Edin and he would address
> this issue soon hopefully.

Can be, but implicit_flush is documented like this (which is correct):

implicit_flush  boolean

FALSE by default. Changing this to TRUE tells PHP to tell the output 
layer to flush itself automatically after every output block. This is 
equivalent to calling the PHP function flush() after each and every call 
to print() or echo() and each and every HTML block. 

It says totally NOTHING about output buffering issues. This change also 
breaks internal functions:


'foo'

(While it should not have dumped the contents at all). Please revert 
this, as this breaks backward compability BIG time, and IMO this is not 
a shortcoming of CLI. BTW, where did you get that implicit_flush should 
disable all output buffers?

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ini_set("register_globals", 1);

[Derick Rethans]

On Thu, 3 Oct 2002, Sascha Schumann wrote:

> The session test scripts need to set register_globals -- does
> anyone see a problem with making that option setable in the
> script?

No, but I wonder how you would like to implement this. Globals are 
put into the corresponding arrays before the script runs...

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ini_set("register_globals", 1);

[Sascha Schumann]

> No, but I wonder how you would like to implement this. Globals are
> put into the corresponding arrays before the script runs...

The session module reads register_globals as well.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ini_set("register_globals", 1);

[Derick Rethans]

On Thu, 3 Oct 2002, Sascha Schumann wrote:

> > No, but I wonder how you would like to implement this. Globals are
> > put into the corresponding arrays before the script runs...
> 
> The session module reads register_globals as well.

Makes sense then. But do you know you can set ini setting in the test 
scripts too, like this:

--TEST--
Check for exif_read_data, Unicode user comment
--INI--
output_handler =
zlib.output_compression = Off
exif.decode_unicode_motorola=UCS-2BE
exif.encode_unicode=ISO-8859-15
--FILE--


I think this should suffice and this also avoids the mis-generation on 
documentation on ini_set("register_globals") (the documentaition is 
generated based on the INI_ constants in the source.

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ini_set("register_globals", 1);

[Sascha Schumann]

On Thu, 3 Oct 2002, Derick Rethans wrote:

> On Thu, 3 Oct 2002, Sascha Schumann wrote:
>
> > > No, but I wonder how you would like to implement this. Globals are
> > > put into the corresponding arrays before the script runs...
> >
> > The session module reads register_globals as well.
>
> Makes sense then. But do you know you can set ini setting in the test
> scripts too, like this:

Thanks for pointing this out.  I'll update the scripts later.

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php