[Jani Taskinen <[EMAIL PROTECTED]>]
>
> (could we have some nice 'codenames' for the releases? Please.. :)
Hey, what if we name them after the third noun on page five of your
(finnish) morning paper at the day of RC1 (using GMT)? :-)
- Stig
--
Stig Sæther Bakken <[EMAIL PROTECTED]>
Fast S
Quoting Hartmut Holzgraefe <[EMAIL PROTECTED]>:
> > arg_separator.output should default to ' '.
>
> ??? i guess it will break lots ;)
>
> maybe we should & instead?
Wow. Yeah, I'm really tired this morning. & is what I meant, of course...
Thanks, Hartmut. :)
-chuck
--
Charles Hagenbuch, <[
Quoting Jani Taskinen <[EMAIL PROTECTED]>:
> And note that in CVS there are now two directives:
>
> arg_separator.input
> arg_separator.output
>
> Both default to "&" thus were not gonna break anything.
arg_separator.output should default to ' '. I can't think of anything that
it'll break, an
On Thu, 5 Apr 2001, Boian Bonev wrote:
>count of boxes broken if arg_separator is '&;'
>count of boxes that dont care about arg_separator default
>count of boxes that need arg_separator to be '&;'
>count of boxes relying on magic_quotes_gpc
>count of boxes that dont care about magic_quotes_gpc
>c
hi,
> > There was a discussion about things to break in 4.1. magic_quotes_gpc
would
> > definitely be my favourite. I'd like to see it set to off for good and
> > removed from php.ini.
>
> I'd be completely against removing the concept of magic_quotes altogether.
> We can discuss changing the def
> Agreed that it's handy and easy, but it's a two-edged sword. If you write
> scripts that should be distributed on many different servers, it takes a lot
> of code to account for both settings.
>
> I'm one of those control freaks ;) that like to be in total charge about
> what data goes in and ou
From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
Sent: Wednesday, April 04, 2001 7:22 PM
> > There was a discussion about things to break in 4.1. magic_quotes_gpc
would
> > definitely be my favourite. I'd like to see it set to off for good and
> > removed from php.ini.
>
> I'd be completely against re
> There was a discussion about things to break in 4.1. magic_quotes_gpc would
> definitely be my favourite. I'd like to see it set to off for good and
> removed from php.ini.
I'd be completely against removing the concept of magic_quotes altogether.
We can discuss changing the default, but for so
At 07:11 PM 4/4/2001 +0200, Edin Kadribasic wrote:
> > But commercial companies aside, the plethora of configuration options
>(like
> > magic_quotes_gpc) can and does make life harder for people writing code
> > libraries (like PEAR) that are meant to be dropped in anywhere, or for
>people
> > try
> But commercial companies aside, the plethora of configuration options
(like
> magic_quotes_gpc) can and does make life harder for people writing code
> libraries (like PEAR) that are meant to be dropped in anywhere, or for
people
> trying to write applications that have minimal setup required, o
Quoting Joey Smith <[EMAIL PROTECTED]>:
> I've never bought into this argument, because these companies
> can include a "config.php", or something like that, which uses
> ini_set() to set up the INI file however they need it...
But commercial companies aside, the plethora of configuration
At 06:55 4/4/2001, Alexander Bokovoy wrote:
>If so, why this change didn't find its way into PHP_4_0_5 branch? It was
>done a week ago, at the time of ~ RC3 I think.
Because changes such as this aren't critical, make break things, and thus
do not belong in RCs.
Zeev
--
PHP Development Mailin
At 00:54 04/04/2001 +0200, Hartmut Holzgraefe wrote:
>[EMAIL PROTECTED] wrote:
> > Please stop crossposting to the PHP-DEV and the PHP-QA mailing list. Most
> > people interesting in this theme are reading both. And so it is really
> > annoying to get everything twice.
>
>a bad idea IMHO as long a
On Wed, 4 Apr 2001, Alexander Bokovoy wrote:
>> Why do you see it as a problem? They should be doing their own
>> releases after our releases. ie. They should say that this version
>> works with PHP 4.0.5. People should know that when they get
>> the bleeding edge..it might not work at all.. Ther
On Wed, Apr 04, 2001 at 12:55:52AM +0200, Jani Taskinen wrote:
> On Wed, 4 Apr 2001, Alexander Bokovoy wrote:
>
> >There is one problem which could come dangerous for extensions in
> >future: change made a week ago in configure macros: AC_ADD_* ->
> >PHP_ADD_* This change was made in HEAD branch
On Wed, 4 Apr 2001, Alexander Bokovoy wrote:
>There is one problem which could come dangerous for extensions in
>future: change made a week ago in configure macros: AC_ADD_* ->
>PHP_ADD_* This change was made in HEAD branch but PHP_4_0_5 wasn't
>reflected. It means that external extensions (PHP-G
On Tue, Apr 03, 2001 at 03:18:00PM -0600, Joey Smith wrote:
> Speaking of this, I think we need to collect all of these types of
> issues that are waiting for a "4.1" release somewhere, so we can get a
> clear idea of when 4.1 is appropriate. Anyone know of any off-hand? If
> not, I can go search
;[EMAIL PROTECTED]>
Cc: PHP Developer List <[EMAIL PROTECTED]>; PHP Quality Assurance
<[EMAIL PROTECTED]>
Sent: Wednesday, April 04, 2001 12:14 AM
Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
> > >> Which reminds me: If arg_separator is used like i
> >> Which reminds me: If arg_separator is used like it was before my patch
> >> and you set it to e.g. ';' and then have a form which method
> >> is GET..well, it won't work. there would be one variable
> >> holding all the info.
> >
> >Urls that are the result of a submitted form are generated b
On Tue, 3 Apr 2001, Edin Kadribasic wrote:
>> Which reminds me: If arg_separator is used like it was before my patch
>> and you set it to e.g. ';' and then have a form which method
>> is GET..well, it won't work. there would be one variable
>> holding all the info.
>
>Urls that are the result of
> Which reminds me: If arg_separator is used like it was before my patch
> and you set it to e.g. ';' and then have a form which method
> is GET..well, it won't work. there would be one variable
> holding all the info.
Urls that are the result of a submitted form are generated by the browser
and
Just thinking out loud here before I go to bed...how about:
arg_sep.read = "&" | ";"
arg_sep.write = ";"
Or something like this. It'd be nice to be able to do the |.
On Tue, 3 Apr 2001, James Moore wrote the following to Rasmus Lerdorf and...:
>
> > I disagree, we explicitly document that the
On Tue, 3 Apr 2001, Rasmus Lerdorf wrote:
>I disagree, we explicitly document that the arg_separator defaults to &
>and that this is the character that separates url arguments. This follows
>the original CGI specification. The fact that this is no longer the
>accepted standard for this doesn't
Just to reply to myself we are fairly broken here according to rfc 2396 but
if you guys think thats acceptable until 4.1 (whenever that might be) then
thats fine..
Relavant part of RFC:
2.2. Reserved Characters
Many URI include components consisting of or delimited by, certain
special cha
Speaking of this, I think we need to collect all of these types of
issues that are waiting for a "4.1" release somewhere, so we can get a
clear idea of when 4.1 is appropriate. Anyone know of any off-hand? If
not, I can go search the archives...
On Tue, 3 Apr 2001, James Moore wrote the following
> I disagree, we explicitly document that the arg_separator defaults to &
> and that this is the character that separates url arguments. This follows
> the original CGI specification. The fact that this is no longer the
> accepted standard for this doesn't mean we can just up and change it in a
On Tue, 3 Apr 2001, James Moore wrote the following:
> I would question about it being optional in the long term though. If we
> begin to make everything optional then we get to a point where PHP is so
> configurable with enabling this bug here or there it becomes impossible to
> create distrib
I disagree, we explicitly document that the arg_separator defaults to &
and that this is the character that separates url arguments. This follows
the original CGI specification. The fact that this is no longer the
accepted standard for this doesn't mean we can just up and change it in a
minor PH
Just wanted to toss in my .02 here...
Anyone who wrote scripts in the past expecting: foo.php?a=1;2;3 to get
"$a=1;2;3" was relying on a bug, or at the very LEAST an undocumented
feature. So if it goes away, it goes away. It should never have worked
to begin with, IMHO...
This doesn't mean it wo
29 matches
Mail list logo
