Re: [PHP-DEV] PHP 8 Release Announcement Page

[Giovanni Giacobbi]

On Fri, 19 Nov 2021 at 10:13, Pierre  wrote:

> Le 19/11/2021 à 10:10, Kamil Tekiela a écrit :
> > I would suggest option number 5. Leave it as it is. Many people are still
> > not aware that PHP 8 has been released.
> > If that's not possible, then we should keep the page (opt 3), otherwise
> we
> > will be breaking links to it, e.g. on Stack Overflow.
> > Adding PHP 8.1 alongside would be great, but we already have upgrade
> pages,
> > so I'm not sure the effort is worth it.
> >
> Hello,
>
> I do not agree, PHP 8 release page was really nice (even for me daily
> reading internals) and I think it could be a nice tradition to keep.
>
> 8.1 does bring lots of nice stuff, which deserve a nice presentation.
>
>
Why don't you guys keep the same page for the whole 8.x series? You just
need to drop the ".0" and append at the end (maybe stating what's new from
8.1 specifically). The rationale is that people will be migrating from 7.x
for a long time (hell, I'm still maintaining some legacy 5.x projects), so
it would be nice to have all 8.x major language features in one page. Early
8.0 adopters might be better checking the detailed changelog for 8.1 or
just the regular announcement.

Re: [PHP-DEV] PHP 7.2.0 RC6 Released

[Giovanni Giacobbi]

On 9 November 2017 at 18:46, Thomas Hruska  wrote:

> On 11/9/2017 7:36 AM, Sara Golemon wrote:
>
>> The sixth (and likely final) release candidate for 7.2.0 was just
>> released and can be
>> downloaded from:
>> https://downloads.php.net/~pollita/
>> Or using the git tag: php-7.2.0RC6
>>
>> Barring unforeseen calamity, everyone should expect 7.2.0-final on
>> Thursday, November 30th.
>>
>
> Issue #73535?  I consider letting a known security vulnerability that goes
> largely unaddressed but persists into the next major version of a software
> product to be quantifiable as a calamity of sorts.  It's fast approaching a
> full year without any resolution in sight.  Many people would have zero
> day-ed the issue by this point at whatever conferences have come and gone
> (Black Hat, DEF CON, etc.) to grab some quick notoriety.  I don't believe
> that zero day-ing a vulnerability on a stage is the right solution for a
> garden variety of reasons.
>
>
This is utterly disappointing considering that bug #73535 is marked as
private and I couldn't easily gather more information about this bug on
google. Since I have the feeling this is an open secret can you disclose
more information and proposed patches so that sysadmins can assess by
themselves the risks, mitigation techniques, and whether to patch their own
installations?

I guess the dev team wouldn't leave us with our pants down, so I expect
this to of difficult exploitability. Anyway, after a year it's time for
full disclosure, don't you think?

Kind regards
GG

Re: [PHP-DEV] PCRE JIT broken in PHP 7.2

[Giovanni Giacobbi]

On 18 September 2017 at 19:04, Dmitry Stogov  wrote:

> This commit should fix the problem https://github.com/php/php-src/commit/
> 5ef10d08ec2d0823fb21ad189dacfb43d900a0b5
>
>
> Yes! I tested 7.2.0RC2 with this patch applied and it fixes the problem.
Thank you!

Re: [PHP-DEV] PCRE JIT broken in PHP 7.2

[Giovanni Giacobbi]

On 18 September 2017 at 13:46, Dan Ackroyd <dan...@basereality.com> wrote:

> On 18 September 2017 at 12:28, Giovanni Giacobbi <giova...@giacobbi.net>
> wrote:
> >
> > just an heads up, I started testing my project with PHP 7.2.0RC2 but it
> was
> > causing a segmentation fault.
>
> Even if you think bugs are urgent enough to email the internals list -
> please open a bug report at bugs.php.net first, so that people can
> response to it without spamming the list.
>
>
The attitude in this ml is always very challenging.

Yes, a bug that completely brokens a working environment when upgrading
from 7.1.9 to 7.2.0, while we are in RC2 stage, I think it's quite urgent
and requires attention.

Anyway, the bug has been filed as #75223

> If you need any further information let me know.
>
> "See how to get a backtrace in case of a crash":
> https://bugs.php.net/bugs-generating-backtrace.php
>
>
I believe who worked on the PCRE support (the problem is either the bundled
pcre library update or the JIT fast path API), might have enough
information, otherwise if they kindly request the backtrace I will provide
it.

Of course I'm also fine sticking with 7.1.9 and waiting for someone else to
incur in the problem and wait until it's fixed.

-- 
Giovanni Giacobbi

[PHP-DEV] PCRE JIT broken in PHP 7.2

[Giovanni Giacobbi]

Greetings,

just an heads up, I started testing my project with PHP 7.2.0RC2 but it was
causing a segmentation fault.

I tracked down the problem to preg_match(), in particular when JIT is
enabled and ONLY when running through Apache2 with event MPM. This problem
does not occur with command line invocation.

Here are the versions I tested, same environment:
7.1.9  works with PCRE JIT enabled
7.2.0alpha1   broken
7.2.0rc2  broken

Build command line:
./configure \
  --with-apxs2=/usr/local/apache2/bin/apxs \
  --with-fpm-user=httpd \
  --with-fpm-group=httpd \
  --disable-cgi \
  --enable-intl \
  --with-layout=GNU \
  --enable-maintainer-zts \
  --with-gettext=static \
  --with-iconv \
  --with-mysqli=mysqlnd \
  --enable-exif \
  --with-openssl \
  --with-curl

The effect i observed is the following:

var_dump(preg_match('/^a/', "a"));=> int(0)
var_dump(preg_match('/a/', "a")); => segmentation fault

If you need any further information let me know.

Kind regards

-- 
Giovanni Giacobbi

Re: [PHP-DEV] json_encode() / json_decode() warnings

[Giovanni Giacobbi]

On 27 July 2017 at 18:00, Craig Duncan <p...@duncanc.co.uk> wrote:

> On 27 July 2017 at 16:57, Niklas Keller <m...@kelunik.com> wrote:
>
> > It should rather just throw exceptions. Warnings do not really allow
> error
> > handling, they just allow error reporting.
> >
> >
> Agreed, but I can't see Exceptions passing the vote. Warnings can be
> silenced by those that don't care and converted to Exceptions by those that
> do
>

Error management is a painful topic in PHP, expecially when considering to
the way fopen() behaves, where you *need* to use the "@" suppression if you
want it to behave the way you expect it to behave.

About Exceptions you can easily build a framework around core functions,
for example this is in my core library for all projects:

```php
function safe_json_decode($json = null) {
  if ($json == "")
return null;

  $retval = json_decode($json, true, 512, JSON_BIGINT_AS_STRING);
  if (json_last_error() != JSON_ERROR_NONE)
throw new JsonDecodeException(json_last_error_msg(), json_last_error());

  return $retval;
}
```

So yes, the behaviour of json_decode() might not be optimal, but it's fine
the way it is.

-- 
Giovanni Giacobbi

Re: [PHP-DEV] Add is_vectorlike($array) function

[Giovanni Giacobbi]

On 2 May 2017 at 11:55, Rowan Collins  wrote:

> On 02/05/2017 10:13, Jesse Schalken wrote:
>
>> Related to the optimisation made by Sara Golemon here:
>> https://github.com/php/php-src/commit/c74bc87c74f48bc55541b3
>> bf2fc67d595f58a3b5
>>
>> I often define a function like this, which checks if an array is "vector
>> like" i.e. has keys 0,1,2..N:
>>
>> function is_vectorlike(array $a): bool {
>>$i = 0;
>>foreach ($a as $k => $v) {
>>  if ($k !== $i++) {
>>return false;
>>  }
>>}
>>return true;
>> }
>>
>>
> +1, I've been thinking of making a similar suggestion. We can bikeshed the
> name (it should certainly start with "array_"), but I think there's a very
> good case for having an optimised implementation built in, given the
> opportunities for short-cutting based on representation details.
>
>
Wouldn't be better to introduce a new native type "vector"? I know it
sounds obnoxious introducing a new basic data type, but I think having a
workaround like is_vectorlike() wouldn't completely address the problem.

Other than serializations I also felt, many many times, the need to also
type-hint the input parameters with vector:

function do_something(array $a) {
  if (!is_vectorlike($a))
throw new Exception("I don't like the input");
  // do something with $a
}

I feel like going back to the dark ages when I had to manually check for
is_string(), is_int() on the input parameters. Think how much better it
would be to be able to:

function do_something_ex(vector $a) {
  // do something with $a
}

Also it would be perfectly acceptable to implicitly cast a vector to an
array, since a vector is basically a packed array.

How does it sound? Complete madness?

  $a = [ "a", "b", "c" ];
  is_vector($a); // true
  is_array($a); // true
  unset($a[1]);
  is_vector($a); // false
  is_array($a); // true

Re: [PHP-DEV] Allow "static" type

[Giovanni Giacobbi]

On 28 January 2017 at 10:18, Wes <netmo@gmail.com> wrote:

> Hi​, static could be definitely a valid return type, but I don't see this
> happening for parameters, for the same reasons this is disallowed:
>
> class A{ function bar(A $a){} }
> class B extends A{ function bar(B $b){} } // must be contravariant, but B
> is covariant to A
>
>
That's not completely true, the contravariance rule exists to defend the
polymorphism and overriding, BUT this is a static scope so it is *almost*
like an overloading, I.E. B will have *another* method bar which is
different from A's, the only difference is that B should also inherit
original's A::bar but it does not, it's like A::bar(A) is not inherited.

Before anyone say it, I know you can use the $a::bar() syntax to invoke
static methods, but I consider that a shorthand of A::bar() and what people
should *always* use unless they have complete control over the code and
invocation stacks.

I did in fact hit a use for this feature a long time ago where I wanted to
have a static method which is able to operate (in my case delete from
database) an instance of an object, and I solved it WAY before the
introduction of all this syntactic madness I've been witnessing recently,
which is:

  public static function delete(self $object) {
$class = get_called_class();
$baseclass = get_class($object);
assert('($class == $baseclass) || is_subclass_of($class, $baseclass)');
// do whatever you need to do
  }

The reason is that I always want the caller to be aware of what he is doing
and never use the "standard" method on a subclass which actually redefines
it.

Even though I like the proposal and I would personally use it, I'm against
it because I think PHP has been getting a lot of "features" which only safe
a few keystrokes in very edge cases but complicate the language and steep
the learning curve, which was the only real strong point of PHP, its
simplicity.

I think the latter thought is a bit offtopic, one day I will start a thread
to start philosophizing on the direction PHP had taken the past years (good
old times when the strict type hinting was rejected because it made it too
complicated for newcomers, lol).

Cheers

-- 
Giovanni Giacobbi

[PHP-DEV] String to array odd behaviour in 7.1

[Giovanni Giacobbi]

Greetings,

There is something weird with 7.1 and implicit strings to array
conversions, so I wanted to double check with you that the behaviour is
wanted (and perhaps the migration71 doc should be updated to reflect this.

So in the migration docs [1] you say that: " Applying the empty index
operator to a string (e.g. $str[] = $x) throws a fatal error instead of
converting silently to array. "

I'm going to show four cases on different PHP versions:

CASE 1: php -r '$a = "foo"; $a[] = "bar"; var_dump($a);'
PHP 5.6.x -> Fatal Error
PHP 7.0.x -> Fatal Error
PHP 7.1.x -> Fatal Error

CASE 2: php -r '$a = "foo"; $a["x"] = "baz"; var_dump($a);'
PHP 5.6.x -> string "boo" (with illegal offset warning)
PHP 7.0.x -> string "boo" (with illegal offset warning)
PHP 7.1.x -> string "boo" (with illegal offset warning)

CASE 3: php -r '$a = ""; $a["x"] = "bar"; var_dump($a);'
PHP 5.6.x -> array("x" => "bar") with NO warnings
PHP 7.0.x -> array("x" => "bar") with NO warnings
PHP 7.1.x -> string "b" with illegal offset warning

CASE 4: php -r '$a = ""; $a[] = "bar"; var_dump($a);'
PHP 5.6.x -> array("bar") with NO warnings
PHP 7.0.x -> array("bar") with NO warnings
PHP 7.1.x -> Fatal Error

I think what is bugging me here is that the docs talk about CASE 1 whose
behaviour actually did not change, so it should mention "empty string"
because that's where the actual change happened (CASE 4), also I think that
CASE 3 should be rethinked.

In general I would like to raise a concern on the fact that I think the
previous behaviour was better, after all PHP is dynamically typed so why
not allow a variable to silently change its value silently? We know that
using offset with strings is always illegal (CASE 2) so why not *always*
converting it to an array and discard its previous value?

[1]
http://php.net/manual/en/migration71.incompatible.php#migration71.incompatible.empty-string-index-operator

Re: [PHP-DEV] Explicit constructor call and polymorphic dispatch

[Giovanni Giacobbi]

You are right, I feel responsible for it (but proudly), as an excuse please
consider that the three topics covered have a certain dependancy:

Forbid __construct calls -> Forbid in constructor as well for coherency ->
need a new way to call parent's constructor
(bonus topic: implicit constructors)

It would be a pity if only the first part made it into the core, and I
personally like it plus I always wanted a better way to invoke parent's
constructor, so I threw it in the basket, but you are right, it is quite
off-topic. I'll check out the guide on how to submit RFCs so you guys can
fry me in another thread :P

On 15 January 2017 at 07:06, Wes <netmo@gmail.com> wrote:

> you guys went slightly off topic :P
>



-- 
Giovanni Giacobbi

Re: [PHP-DEV] Explicit constructor call and polymorphic dispatch

[Giovanni Giacobbi]

I'm surprised no one is raising a strong argument about the
"parent::__construct()" call, so I'll do it.

I never liked typing "parent::__construct()" to call parent's class
constructor, but now that this proposal is being discussed (and might even
be accepted) I would like to throw some more meat to the fire:

__construct(10, 20); so
I don't see why I should type that method name inside my derived
constructor. I just need a special syntax to do so.

And while I'm at it (a bit offtopic but related to my previous argument)
how about *not* requiring __construct() to be defined in the parent class?
I.e. when you call parent::__construct() if there is NO constructor defined
in the parent class just do nothing instead of going fatal error. I
*always* wanted this feature, because when you do "new C;" it doesn't go
fatal error if there is no __construct() defined. I don't think this is
breaking covariance if you assume that every class defines an empty
__construct() with no argument. I mean, if you later add an explicit
constructor to the parent class it *must* be without arguments unless you
accept you might break something.

Thanks!


On 14 January 2017 at 13:15, Andreas Heigl <andr...@heigl.org> wrote:

>
>
> > Am 14.01.2017 um 11:26 schrieb Fleshgrinder <p...@fleshgrinder.com>:
> >
> >> On 1/14/2017 11:20 AM, Andreas Heigl wrote:
> >> Do we as "makers of PHP" want to dictate the user what the "intended"
> >> behaviour of PHP is? Or are we treating the user as a responsible person
> >> that knows what to do and also not to do?
> >>
> >> Personally I'm in favour of the later. Let the user be able to call
> >> __construct whenever they like. It's a special method which is clearly
> >> visible by the two underscores at the start. So the users either know
> >> exactly what they are doing or they need to learn it.
> >>
> >> Translated to a different example this discussion is like: "Let's remove
> >> the handle from the window because someone might be able to open the
> >> window and jump out of it". The handle is there for a valid reason. And
> >> as a window-maker I have no idea in what way it might be used. But I
> >> have to accept that there are people missusing it. But should I limit
> >> all those users with a valid use-case for it just to save some from
> >> missusing it? And if we start with that, where should we stop?
> >>
> >> Just my 0.02€
> >>
> >> Cheers
> >>
> >> Andreas
> >>
> >
> > Yes, that is exactly the question. This needs to be voted on. Rust would
> > be an example that protects you and C/C++ would be examples that do not.
> > Both approaches are valid approaches.
> >
> > Note that the dictation will not always work, this is why e.g. Rust has
> > unsafe blocks. The corresponding thing in PHP imho would be reflection.
> > Hence, if someone has a special case:
> >
> > - Rust: use unsafe
> > - PHP: use reflection
> >
> > --
> > Richard "Fleshgrinder" Fussenegger
>
> IMHO it already IS safe.
>
> In PHP 4 the "constructor" was a method thad had the same name as the
> class. But now it is a class that has always the same name and is always
> preceded with two underscores. There is no way to "accidentaly" call that
> method. You have to explicitly call "__construct" to "break" things.
>
> If developers "want" to break something they will find a way. Protecting
> "__construct" will not stop them from doing so. But it will stop the rest
> of us do legitimate things.
>
> Cheers
>
> Andreas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Giovanni Giacobbi

Re: [PHP-DEV] Throwable and Error exceptions break existing PHP 5.x code

[Giovanni Giacobbi]

I want to thank Markus and Björn for getting me up to speed with the
pointers.
Please see the rest of my response below.

On 11 January 2016 at 15:05, Rowan Collins <rowan.coll...@gmail.com> wrote:

> Giovanni Giacobbi wrote on 11/01/2016 13:31:
>
>> set_exception_handler(callback function, bool also_throwables = false);
>>
>> The new parameter "also_throwables" defaults to false, so the same
>> behaviour as before is preserved. If you want it to catch also the new
>> PHP7
>> Error exceptions, you can just set it to true.
>>
>
> This is an interesting idea, but other than the specific transition to PHP
> 7, I'm not sure when it would be used.
>
> Put it this way: if Errors existed when you first wrote this code, would
> you want to handle them using your custom handler functions, or would you
> prefer them to the fall through to the default server White Screen of Doom?
> My guess is that you'd want to pass them to the handler, even if it
> immediately checked "if ($e instanceOf Error)" and used a different output
> style.
>
>
I would *obviously* use this mechanic if it was available, I'm sure I'm not
the only one frustrated by the fact that it was not possible to cach fatal
errors and had to make stunts with apache's error log to do some complete
error auditing.But the fact is that it did NOT exist, so when you say
"other than the specific transition to PHP 7", well I think it is a big
deal and motivates the introduction of a new feature just for that.

Since set_exception_handler() is intended as a last-ditch "something's gone
> very wrong" function anyway, I think it receiving all Throwables makes
> sense, even if the BC break in your scenario is unfortunate.
>
>
Yes, it is very unfortunate. Not for the two lines of codes that required
to fix the issue (I wrapped it in a if ($e instanceof Exception) { ... }
block), but because of the feeling this gave me about the general attitude
towards the community.

I love PHP and I enjoy programming in it, and I always defend it when my
peers and collegues talk [really] bad about it. In the past I always felt
that BCs I got in my project were inevitable or caused by poor
implementation or not strictly adhering to the documentation guidelines.
This is why when we migrated from PHP 4 to 5.2 we rewrote most of the code.
It was a big effort, but we did it by checking the documentation all the
time, respecting deprecates, and so on. Because of this migrations from 5.2
to 5.3 and 5.3 to 5.6 were painless, close to zero changes or just bugs
catching. Everything was done by the book.

Now comes this breakage, but this time, funny to say, I felt stub in the
back. That's why after years of being in read-only mode I decided to speak
up.

I identified two possible indipendent change paths, which I'd like you to
consider separately. Both seem better than my initial idea of the boolean
flag in set_exception_handler():

1) Check the handler's signature compatibility before calling it.
Indeed there is no reason to fix a my_hnd(Exception $e) and not a
my_hnd(ExceptionA $e) where class ExceptionA extends Exception, so this
proposal would be to simply ignore the set_handler_exception()'s callback
if it is not compatible, or maybe even better issue an E_NOTICE or E_STRICT
in such case.
Although it doesn't completely solve the original problem, it mitigates it
and makes the engine look better, as it comes at very little cost and
*zero* BC breaks (code wouldn't work anyway).

2) Introduce set_throwable_handler() and leave set_exception_handler() as
it was in PHP 5.x, i.e. catching only Exception descendants.
Indeed this is what I expected to see, i.e. everything worked as before,
and if I want to exploit this new powerful feature I have to "enable" it by
change just one single line of code!
Unfortunately as PHP7 is released this would hironically be BC break itself
now, so I understand it is never going to happen, but I want you to
consider it nonetheless to at least introduce set_throwable_handler() even
if set_exception_handler() stays broken (maybe mitigated by the change 1).
Also think about the possible upcoming changes to the Throwable definition,
I saw in another thread that you are thinking about dropping
Throwable::getCode(), which would make things even worse, in case of
something as simple as:
set_exception_handler(function($e) { print $e->getCode(); });

Thank you for listening to me, I want to stress that I really appreciate
what you do even when I disagree with it.

Kind regards
Giovanni

[PHP-DEV] Throwable and Error exceptions break existing PHP 5.x code

[Giovanni Giacobbi]

Greetings,

Short premise before I get flamed: I know PHP 7 is rolling and it is way
too late for this, that I should've tested the RCs, follow the mailing list
and so on, but I'm a dev like you guys and struggle with the time to do
everything by the book, including reading the previous threads because I'm
pretty sure this was brought up by somebody, but as there are hundreds of
message under the "Throwable" topic and I can't read all of them.

In short I have this situation:



This happens because the specific handler will output the exception
according to the expected format (HTML, JSON, or even an image).

Now after upgrading to PHP7 when one of the new Error exception is thrown,
I get the following error:

PHP Fatal error:  Uncaught TypeError: Argument 1 passed to
SpecificHandler::exception() must be an instance of Exception, instance of
Error given, called in [...]

Having been a PHP dev for 10 years now I know that the policy is to try to
break as little as possible while implementing new features, and I like
that. I know that sometimes things must be broken to progress, but in this
case maybe there is a very simple fix that I can suggest to avoid breaking
existing code, change set_handler_exception like this:

set_exception_handler(callback function, bool also_throwables = false);

The new parameter "also_throwables" defaults to false, so the same
behaviour as before is preserved. If you want it to catch also the new PHP7
Error exceptions, you can just set it to true.

What is your take on this? I know I can easily fix my code to work on both
PHP 5.x and PHP 7.x, but I really disliked this kind of BC.

Kind regards
Giovanni

[PHP-DEV] Re: Big patch for FPM (config and initialization)

[Giovanni Giacobbi]

Sorry I always forget this mailing list is special and strip my attachments...

Here is a link:
http://pastebin.com/7JpXr22c

On Sun, Jul 3, 2011 at 02:50, Giovanni Giacobbi giova...@giacobbi.net wrote:
 Greetings dear devs!

 A few days ago I made my first nginx+php-fpm setup, and I soon
 realized some gaps of the current FPM implementation. First of all,
 the lack of documentation, which of course I know I cannot complain
 about, but this forced me to dig into the source code which in turn
 motivated me to write this patch, which is good.

 The patch (attached) is for the current PHP 5.3 svn branch, but if you
 are interested in merging it in I will of course port it to 5.4
 branch. I don't see particular reasons to apply it to 5.3, I was
 working on it because I'm planning to use it in my production
 environments. It would be really nice if it could make it in the 5.4
 because it contains also some name changes in the ini file variables
 (with BC of course).

 The biggest and most interesting change is for sure the introduction
 of a [defaults] config section. More about this below, first the
 complete changelog of my patch:

 Detailed changelog of the patch:
 - Renamed options pm.status_path, ping.path, ping.response into
 a new logical group diagnostics, so they are now respectively:
     diagnostics.status_path, diagnostics.ping_path,
 diagnostics.ping_response.
 - Reordered in a more logical way the pool ini options, from a
 most-likely-to-be-customized first to the least. Usually when you edit
 config file you have big concentration on the first few settings, then
 you go like blah blah defaults defaults and so on, so this kind of
 order makes sense.
 - Aligned all the code listings of pool options with the official
 order to ease auditing. The official order is the one reported in
 the struct definition in fpm_conf.h, which of course is the same as
 the php-fpm.conf.in config template
 - Improved error messages. A better message helps new adopters to get
 started quickly, at the beginning I was really puzzled in front of
 some not very helpful messages.
 - Introduced a new section [defaults] that allows setting default values
 - Dropped restriction of not setting the same value multiple times,
 the last one holds
 - Removed a lot of redundant checks that are logically implied or not
 really required, without reducing the robustness of the program.
 - Improved a lot code readability in some parts, plus added some
 useful comments in the parts that were less easy to understand.
 - Refactored some functions to be shorter from code lines point of
 view, while still doing exactly the same function.
 - Various white space and cosmetic code improvements
 - Moved macros STR2STR, BOOL2STR, and PM2STR from fpm_conf.h to
 fpm_conf.c, no reason to make them public since that's the only file
 using them,
   so in case we need to change them in the future, there is less risk
 of breaking something which depends on them.
 - Fixed a memory leak in fpm_conf_expand_pool_name() (previous
 dynamically allocated *value was lost)

 Now about the new [defaults] section of the config file.
 In the current version if you want to make a decent looking config
 file you have to do something like that:

 [global]
 ...your global stuff...

 [pool1]
 user = pool1
 listen = ...
 include = pool_defaults.conf

 [pool2]
 user = pool1
 listen = ...
 include = pool_defaults.conf

 and so on, plus of course you need the external file pool_defaults.conf.

 With these changes, you can now do something like this:

 [global]
 ...your global stuff...

 [defaults]
 ...my defaults valid for every pool...
 pm.max_children = 500
 pm.start_servers = 10

 [pool1]
 user = pool1
 listen = ...

 [pool2]
 user = pool2
 listen = ...

 [pool3]
 user = pool3
 listen = ...
 pm.start_servers = 20


 There is also a small gain in the parsing time, because defaults are
 propagated in memory instead of parsed multiple times as with the
 include files solution. I have to admit this argument is quite
 irrilevant because it's only a startup time overhead, but it's so much
 more elegant in my eyes.

 Also by dropping the constraint of setting strings only once, you can
 override your defaults in the pools, so you can have an access log
 format for all of them except one.


 Upcoming changes that would follow from me if you accept this patch:
 1) allow '$pool' variable to be used in the [globals], but this
 requires a bit of restructuring because it needs to be lazy-expanded
 in post process time instead of parsing time.
 2) possibility to include more than one file per section


 Looking forward to have some feedback from you :)

 Kind regards

 --
 Giovanni Giacobbi




-- 
Giovanni Giacobbi

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

Re: [PHP-DEV] Big patch for FPM (config and initialization)

[Giovanni Giacobbi]

On Sun, Jul 3, 2011 at 22:42, Antony Dovgal t...@daylessday.org wrote:
 On 07/03/2011 04:50 AM, Giovanni Giacobbi wrote:

 Detailed changelog of the patch:
 - Renamed options pm.status_path, ping.path, ping.response into
 a new logical group diagnostics, so they are now respectively:
     diagnostics.status_path, diagnostics.ping_path,
 diagnostics.ping_response.

 I'm not quite sure renaming config options would help anybody, in my opinion
 it would do more harm than good.
 I personally would certainly expect my existing config files to continue to
 work after upgrade to 5_4.
 Yes, we're changing '3' to '4' in the version number, but that doesn't mean
 we can just go ahead and break the config file.


In fact I don't break them, probably I should've specified it more
clearly, but the previous names are still well accepted:
+   /* Backward compatibility options, to be removed in the next major 
release */
+   { ping.path,  fpm_conf_set_string,
WPO(diag_ping_path) },
+   { ping.response,  fpm_conf_set_string,
WPO(diag_ping_response) },
+   { pm.status_path, fpm_conf_set_string,
WPO(diag_status_path) },
+

I can also add a deprecated warning at boot time if you wish. Anyway,
the patch is too big, I admit, if you don't want to accept the change
name I can create another patch without it. But the first time I read
the config file I had a strong feeling that pm.status_path and
ping_path were related that's why i set them to:
/somesecretname/fpm-status
/somesecretname/fpm-ping
Aren't you doing something like that too?

About the testing, well it works, but I didn't test it thoroughly.
Actually I already found a couple of bugs. Who is the official
maintainer of the FPM? If he is OK to merge it then I will do a very
careful test and I will also write some test cases for the config file
parsing (not sure if there is a test suite for that already, didn't
check carefully).

Thank you for your positive feedback :)

-- 
Giovanni Giacobbi

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

[PHP-DEV] Big patch for FPM (config and initialization)

[Giovanni Giacobbi]

Greetings dear devs!

A few days ago I made my first nginx+php-fpm setup, and I soon
realized some gaps of the current FPM implementation. First of all,
the lack of documentation, which of course I know I cannot complain
about, but this forced me to dig into the source code which in turn
motivated me to write this patch, which is good.

The patch (attached) is for the current PHP 5.3 svn branch, but if you
are interested in merging it in I will of course port it to 5.4
branch. I don't see particular reasons to apply it to 5.3, I was
working on it because I'm planning to use it in my production
environments. It would be really nice if it could make it in the 5.4
because it contains also some name changes in the ini file variables
(with BC of course).

The biggest and most interesting change is for sure the introduction
of a [defaults] config section. More about this below, first the
complete changelog of my patch:

Detailed changelog of the patch:
- Renamed options pm.status_path, ping.path, ping.response into
a new logical group diagnostics, so they are now respectively:
    diagnostics.status_path, diagnostics.ping_path,
diagnostics.ping_response.
- Reordered in a more logical way the pool ini options, from a
most-likely-to-be-customized first to the least. Usually when you edit
config file you have big concentration on the first few settings, then
you go like blah blah defaults defaults and so on, so this kind of
order makes sense.
- Aligned all the code listings of pool options with the official
order to ease auditing. The official order is the one reported in
the struct definition in fpm_conf.h, which of course is the same as
the php-fpm.conf.in config template
- Improved error messages. A better message helps new adopters to get
started quickly, at the beginning I was really puzzled in front of
some not very helpful messages.
- Introduced a new section [defaults] that allows setting default values
- Dropped restriction of not setting the same value multiple times,
the last one holds
- Removed a lot of redundant checks that are logically implied or not
really required, without reducing the robustness of the program.
- Improved a lot code readability in some parts, plus added some
useful comments in the parts that were less easy to understand.
- Refactored some functions to be shorter from code lines point of
view, while still doing exactly the same function.
- Various white space and cosmetic code improvements
- Moved macros STR2STR, BOOL2STR, and PM2STR from fpm_conf.h to
fpm_conf.c, no reason to make them public since that's the only file
using them,
  so in case we need to change them in the future, there is less risk
of breaking something which depends on them.
- Fixed a memory leak in fpm_conf_expand_pool_name() (previous
dynamically allocated *value was lost)

Now about the new [defaults] section of the config file.
In the current version if you want to make a decent looking config
file you have to do something like that:

[global]
your global stuff...

[pool1]
user = pool1
listen = ...
include = pool_defaults.conf

[pool2]
user = pool1
listen = ...
include = pool_defaults.conf

and so on, plus of course you need the external file pool_defaults.conf.

With these changes, you can now do something like this:

[global]
your global stuff...

[defaults]
my defaults valid for every pool...
pm.max_children = 500
pm.start_servers = 10

[pool1]
user = pool1
listen = ...

[pool2]
user = pool2
listen = ...

[pool3]
user = pool3
listen = ...
pm.start_servers = 20


There is also a small gain in the parsing time, because defaults are
propagated in memory instead of parsed multiple times as with the
include files solution. I have to admit this argument is quite
irrilevant because it's only a startup time overhead, but it's so much
more elegant in my eyes.

Also by dropping the constraint of setting strings only once, you can
override your defaults in the pools, so you can have an access log
format for all of them except one.


Upcoming changes that would follow from me if you accept this patch:
1) allow '$pool' variable to be used in the [globals], but this
requires a bit of restructuring because it needs to be lazy-expanded
in post process time instead of parsing time.
2) possibility to include more than one file per section


Looking forward to have some feedback from you :)

Kind regards

-- 
Giovanni Giacobbi

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

[PHP-DEV] BC break in 5.3.2 - 5.3.3 with parent:: and __call/__callStatic

[Giovanni Giacobbi]

Greetings,

in reference to bug #52713 i'd like to inquire you about this decision which 
actually broke my codebase in different parts.

The situation is this one:

class ActiveRecord {

  public function __call($method, $args) {
if ($method == getFoo) {
  // implement some default behaviour for getFoo()
}
  }

  public function __callStatic($method, $args) {
// do some other stuff
  }
}


class Bar {
  // override getFoo() to add some specific behaviour
  public function getFoo() {
// do the specific stuff
parent::getFoo();
  }
}


Until version 5.3.2 this worked fine, starting from version 5.3.3 
parent::getFoo() calls __callStatic() instead of __call().

This is a really bad BC change which i thought you decided to accept only in 
minor versions change and not patch-level versions change.

Anyway, I would even be willing to do some changes to my codebase, but what is 
the solution? I can't see any other way to do this with the obvious assumptions 
that my design is good and that I don't know anything about the parent class 
except there is a getFoo() method implemented somehow.

My wish is that you restore the 5.3.2 behaviour, which sounds very reasonable, 
and maybe introduce another way when you actually want to get rid of the 
context, something like static::

-- 
Giovanni Giacobbi

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

Re: [PHP-DEV] BC break in 5.3.2 - 5.3.3 with parent:: and __call/__callStatic

[Giovanni Giacobbi]

On Mon, Oct 25, 2010 at 01:04:00AM +0200, Etienne Kneuss wrote:
 On Oct 25  0:56:28, Etienne Kneuss wrote:
   
   I think you meant Bar to extend ActiveRecord? But anyway, I think
   that this particular call should be done through __call, not
   __callStatic, since it's basically non-static call. The line between
   the two wasn't really well-defined in PHP (you could call static
   methods non-statically and vice versa) which is a pity but I think
   distinction can be made in this case.
  
  Exactly, if Bar::getFoo is not called statically, parent::getFoo() will
  not be a static call, it should not get through __callStatic.
  
  Best,
 
 Oh, and #51176 seems bogus to me. :: is not sufficient to indicate a
 static call, neither is self::, static::, or Foo::.
 
 A call is only static if one of the two following conditions match:
 1) the target method is declared as static
 2) the call comes from an object-less scope
 

I think you perfectly got the point. However, being actually non-defined, we 
need to choose between __call() and __callStatic(), and i think that number 2 
is the only applicable criteria.

Note that for my problem, reverting commit 295706 in branch PHP_5_3 is enough 
to fix my problem, but it would break again 51176.

As this is a BC break compared to the 5.3.x series, IMHO it's the right way to 
go and then find another solution for 51176.

-- 
Giovanni Giacobbi

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

Re: [PHP-DEV] [PATCH] #52563: Adding E_NONE and/or E_EVERYTHING constants

[Giovanni Giacobbi]

On Tue, Aug 24, 2010 at 11:14:05AM -0700, Stas Malyshev wrote:
 Hi!
 
 use an E_ constant with error_reporting and not have the current
 situation where sometimes you use a constant (or constants) and
 sometimes you use a bare number, depending on what you want to
 achieve.
 
 What's wrong with using 0? 0 means nothing, how hard is that? ` 

Nothing wrong in using 0, but it would be much more elegant to
stick to constants all from the same family. Someone already
figured that out:

 $ php -r 'print_r(get_defined_constants());' | grep ' 0' | wc -l
89

Anyway, my opinion is I would like E_NONE in next major release,
and I would also like E_ALL to be extended to include E_DEPRECATED and
E_STRICT, instead of adding a really bogus E_DEVELOPMENT or E_EVERYTHING.

Please also note that E_* indicates a single error channel, with the
exception of E_ALL and possibly E_NONE if it gets added. I would avoid
adding more E_* constants which don't represent a single channel. I
would find it confusing.

2c

-- 
Giovanni Giacobbi

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

Re: [PHP-DEV] Type hinting - Request for Discussion

[Giovanni Giacobbi]

On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
 
 For example, instead of:
 
 function addFive(int $x) {
   return $x + 5;
 }
 
 You would simply do:
 
 function addFive(is_numeric $x) {
   return $x + 5;
 }
 
 Since $x is guaranteed to be numeric, it is safe to to arithmetic on
 it. No reason to explicitly type cast here.
 


Please let me state that this is the greatest idea I read since the type 
hinting discussion began (and the only one I personally like, as I find all the 
other proposals really disappointing).

I'd like to see some real debating about this syntax proposed by troels:

function addFive(is_numeric($x)) {
  ...
}

Because I really like the idea of passing other parameters:

function check_multiple($a, $b) {
  return !($a % $b);
}

function doSomething(check_multiple($a, 3)) {
  // assume that $a is a multiple of 3
}


This solves all the problems I've understood so far:

- BC breaks for new reserved keywords 'int', 'float', ...: there is no need for 
them anymore

- weak typing vs strict typing:
function cast_bool($value) { $value = (bool) $value; return true; }
function weak_type_hinted(cast_bool($a)) { /* assume that $a is bool, no 
fatal errors */ }

- Nullable values:
function is_int_nullable($val) { return is_int($val) || is_null($val); }
function int_or_null(is_int_nullable($a)) { /* either $a is int or it's 
null */ }

- This will also make the error handling consistent where the classic type 
hinting wouldn't cover a particular use case:

 function foo(int $a) { ... }
 function bar($b) {
   if ($b is not appropriated parameter)
 trigger_error(Invalid parameter);
 }

 // a type of error (E_RECOVERABLE or TypeCheckException or whatever)
 foo(inappropriate_parameter);

 // a custom error, which might be *slightly different* from the one generated 
by the inner php engine
 bar(another_inappropriate_parameter);


I think this gives the perfect freedom to the developers and makes everyone 
happy. I know your concerns about third party libraries that you might have to 
deal with, but if you trigger one of those errors, then it means you are not 
respecting the APIs, which means there is a bug in your application.


-- 
Giovanni Giacobbi

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

Re: [PHP-DEV] Type hinting - Request for Discussion

[Giovanni Giacobbi]

On Fri, Jul 10, 2009 at 01:40:47PM +0200, Lukas Kahwe Smith wrote:
 
 On 10.07.2009, at 13:20, Lewis Wright wrote:
 
 3)  function Foo(is_int($x)) {
 
 Function is_int is called, an error is raised if it returns false.
 
 
 But then you're complicating it to the point where it's no longer  
 much more
 useful than just calling the is_numeric method in the function body.  
 Plus
 there's no longer the advantage of optimisers knowing the data-type.
 
 
 right .. lets not forget the original goal (though it hasnt been  
 perfectly defined)
 the idea was to move common validation code out of the function body  
 to reduce code, increase readability and enable IDE's to be even  
 smarter.
 moving the function body into the signature was not the plan, as it  
 will kill the above features for the sake of flexibility.
 the point is not flexibility, its finding a sensible common  
 denominator for validation of input parameters and optimizing the  
 syntax for that case.
 

Well actually I think the idea was to REPLACE the current syntax with the 
contract specification, because it includes both the strict and weak typing, 
plus it adds a powerful extensibility to the type checking system to user 
space. 

Also, we are not moving the function body into the signature, because it's not 
a statement but a specific single function call.

The grammar will be very strict about what goes inside the signature: at most 
one single function name, followed by any number of arguments which can either 
be a $var, or a constant but NOT an expression. It should be possible also to 
use another syntax:

function ContractHint(is_int:$a, $b, is_multiple:$c:5) { ... }

but I prefer the normal notation:

function ContractHint(is_int($a), $b, is_multiple($c, 5)) { ... }

They look like function calls, but they are NOT function calls in fact. The 
executor will call them for each parameter, checking the (bool) returned value 
and raising a detailed error with the current line where the type checked 
function is called.
If you write your own checking code, raising an error with trigger_error(), the 
error line reported will be inside the type checked function, which is not very 
helpful for debugging (in fact I always have to debug_backtrace() to find 
something useful).

There is NO ambiguity with current type hinting, you can still have classes 
with the same name:

class is_int { }

function StandardHint(is_int $a);

IDEs can still act smart because is_int() is a PHP standard function, and we 
could add a few more like cast_int(), and is_int_null().


-- 
Giovanni Giacobbi

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

Re: [PHP-DEV] 5.3.0 stable delayed until next Tuesday

[Giovanni Giacobbi]

On Wed, Jun 24, 2009 at 05:15:47PM +0200, Lukas Kahwe Smith wrote:
 Aloha,
 
 As most of you following this list have noticed, alot of last minute  
 stuff has been brought up. So it goes.
 Johannes and Pierre have put in extra time in trying to still make it  
 for a release tomorrow, however as the stream of patches and open  
 issues has continued even today, we have decided to play it safe and  
 move the release date to next Tuesday. We will package tomorrow  
 evening and push out the release to mirrors next Monday.
 

Do you think it's worth to push out an RC5 and release it as 5.3.0 only 
changing the version number between them? I saw other projects doing this and I 
think it helps to prevent major issues due to last-time fixes. I have this 
feeling that 5.3.0 release is going to be traumatic!

Just my 2 cents.

-- 
Giovanni Giacobbi

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

Re: [PHP-DEV] PHP 5.2.10

[Giovanni Giacobbi]

On Thu, May 14, 2009 at 10:04:36PM +0200, Pierre Joye wrote:
 hi Ilia,
 
 On Thu, May 14, 2009 at 8:54 PM, Andrei Zmievski and...@gravitonic.com 
 wrote:
  Jani Taskinen wrote:
 
  It's still new stuff. And we need more things in 5.3/6 to make them more
  interesting to general populus too. ;)
 
  Great, so I'll just end up copying almost all of ext/json code into
  pecl/memcached then. Hooray for loose coupling.
 
 It is actually not about adding features. If I understand correctly
 what Andrei likes to have, it is only about exposing the JSON API.
 That means no code change (no new feature or whatever else) but only
 adding the right PHP_API related declaration to the right place and
 install the json header. That could actually be very useful with no
 impact on the code (userland or extensions).
 
 I think we should allow this change.
 

Sorry if I'm not getting this right, but doesn't he have to explicitly require 
version = 5.2.10 in his pecl/memcached extension? It's not like that with this 
change his extension is going to work for 5.2.x. Requiring = 5.2.10 is such a 
strict requirement that should be replaced with = 5.3.0.

-- 
Giovanni Giacobbi

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

[PHP-DEV] Bug in HTTP stream context causes problems in SoapClient/get_sdl()

[Giovanni Giacobbi]

Greetings,

I recently upgraded to the latest PHP 5.3 snapshot and I found the following 
SoapClient bug:

?php
ini_set(soap.wsdl_cache_enabled, 0);
new SoapClient(http://localhost/ws/catalog?wsdl;);
?

Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: 
Couldn't load from 'http://localhost/ws/catalog?wsdl' : Start tag expected, '' 
not found


The problem turned out to be an invalid interpretation of the HTTP/1.1 protocol 
with Transfer-Encoding: chunked by the HTTP stream context, which caused 
get_sdl() to parse a WSDL including the chunk tags (hex numbers).

Chunked encoding is used by Apache 2.0 when Content-Length is unavailable, 
the data content being sent is large enough, and the protocol is HTTP/1.1.

I initially tried using readfile() but I didn't get the same problem. 
Eventually I could finally reproduce the bug with the following script:

?php
$opts = array('http' = array('method' = GET, 'header' = Accept-language: 
en\r\nConnection: close\r\n));
$context = stream_context_create($opts);
stream_context_set_option($context, http, protocol_version, 1.1);
fpassthru(fopen('http://localhost/ws/catalog?wsdl', 'r', false, $context));
?

I can notice various problems here:

1) All the chunk tags are left in place and the extra newlines are not 
stripped, leading to corrupted data.

2) Without the Connection: close header the stream blocks until http timeout. 
It should instead detect the chunk with 0 bytes and return from the fpassthru().


In the meanwhile, the following patch is a workaround for the problem I had: it 
restores the default HTTP/1.0.

Side note: Shouldn't the last smart_str_appendl() call also contain an EOL?

Side note #2: Is there any way to avoid repeating the same string twice? It's 
very common in the soap extension and I think it's really error prone.

Side note #3: Is it possible to create a test for this bug? Like a raw HTTP/1.1 
response stored in a text file with chunk encoding and a script that loads that 
data...?


--- ext/soap/php_sdl.c.orig 2008-12-31 12:37:12.0 +0100
+++ ext/soap/php_sdl.c  2009-01-25 22:09:14.0 +0100
@@ -3192,14 +3192,16 @@
basic_authentication(this_ptr, headers TSRMLS_CC);
 
/* Use HTTP/1.1 with Connection: close by default */
+#if 0
if (php_stream_context_get_option(context, http, protocol_version, 
tmp) == FAILURE) {
-   zval *http_version;
+   zval *http_version;
MAKE_STD_ZVAL(http_version);
ZVAL_DOUBLE(http_version, 1.1);
php_stream_context_set_option(context, http, 
protocol_version, http_version);
zval_ptr_dtor(http_version);
smart_str_appendl(headers, Connection: close, 
sizeof(Connection: close)-1);
}
+#endif
 
if (headers.len  0) {
zval *str_headers;




Regards

-- 
Giovanni Giacobbi

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

Re: [PHP-DEV] Bug in HTTP stream context causes problems in SoapClient/get_sdl()

[Giovanni Giacobbi]

On Sun, Jan 25, 2009 at 11:06:51PM +0100, Hannes Magnusson wrote:
 
  ?php
  $opts = array('http' = array('method' = GET, 'header' = 
  Accept-language: en\r\nConnection: close\r\n));
  $context = stream_context_create($opts);
  stream_context_set_option($context, http, protocol_version, 1.1);
  fpassthru(fopen('http://localhost/ws/catalog?wsdl', 'r', false, $context));
  ?
 
 Changing the protocol version is at your own risk.
 If you want a full real HTTP support, you have to use the pecl/http extension.
 

Please note that the code above is only as proof of concept, because it 
reproduces what is *currently doing* php_sdl.c:3193, get_sdl() function.

Actually, after further investigation I found that this bug was introduced with 
1.114 by dmitry, fixing bug #43069.

So, if I understood correctly the situation is the following:

1) HTTP stream context does NOT support chunked encoding, so you don't consider 
it a bug
2) SoapClient currently uses HTTP stream context forcing HTTP/1.1 thus enabling 
possible chunked encoding result
3) #43069 should then be reopened waiting for a different solution.
3bis) The workaround proposed in the last comment of the bug report works, but 
as SoapClient is using an unsupported feature, it should be the other way 
around: by default 1.0 (as it is in PHP 5.2) and then it can be forced to 1.1 
php side.

IMHO the only clean solution I can see is by implementing the chunked encoding 
to HTTP context.

@William: I'm not sure I understand your reply: Apache#1 (the one running my 
test code) has nothing to do in all of this, because PHP is opening a raw 
socket and communicating on its own with Apache#2 (the one outputting the wsdl 
with chunked encoding). Thus PHP has to deal with this by itself, you cannot 
consider it a misconfiguration of Apache#2, because it is legitimately using 
the HTTP protocol.

-- 
Giovanni Giacobbi

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

Re: [PHP-DEV] [RFC] prototyping

[Giovanni Giacobbi]

On Thu, Jan 15, 2009 at 10:56:01AM +0100, Lukas Kahwe Smith wrote:
 
 We have worked through the challenge of getting namespaces worked out  
 in 5.3, adding yet another increasingly heavy feature to the syntax  
 would delay us if we really want to make sure we get it right.  
 Screwing up would get us into a world of hurt and to me the main use  
 case we wanted to address was making it easier to define callbacks for  
 our various internal functions.
 

I was wondering, why don't you simply mark the feature as experimental, so 
people that use it know that it might change unexpectedly from one version to 
another, breaking their scripts. Something similar to the Linux Kernel features 
approach.

I've never seen this approach used in PHP development process, I've always been 
seeing the feature freeze - support for a long time - deprecate - remove in 
the next major version approach. Marking a particular language feature as 
experimental would allow you to drop it or to change it without notice even in 
a patchlevel release (5.3.1), resulting in a way quicker and more dynamic 
development process.

The benefits? Nobody (but me...) would install an unstable version of PHP in a 
production environment, but probably some people would taste an experimental 
feature included in a stable version.

Just my 2 cents.
Regards,

-- 
Giovanni Giacobbi

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

[PHP-DEV] SOAP extension and object records

[Giovanni Giacobbi]

Greetings,

I'm a newbie in SOAP, and I'm doing my first experiments using PHP. I suspect 
there is a bug in records processing, but I thought it was useful to discuss it 
here before submitting a possibly bogus bug report.

I'll explain briefly the test case, but before a tiny side note: I've been 
reading thru the ext/soap source code and cleaned up some white spaces. Shall I 
submit that patch?

Back in topic, I define a simple record type:

schema xmlns:tns=urn:testing xmlns=http://www.w3.org/2001/XMLSchema; 
targetNamespace=urn:testing
  complexType name=Product
all
  element name=id type=int /
  element name=title type=string /
  element name=description type=string minOccurs=0 /
/all
  /complexType
/schema

And a simple operation:

  message name=genericObjectId
part name=id type=xsd:int /
  /message
  message name=ProductCommit
part name=product type=tns:Product /
  /message
operation name=ProductCommit
  input message=ProductCommit /
  output message=genericObjectId /
/operation

Now the SOAP envelope. First a complete record but with bogus data (a string in 
place of the int):

?xml version=1.0 encoding=UTF-8?
soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
  soap:Body
product
  idhello/id
  titleProduct name/title
/product
  /soap:Body
/soap:Envelope

So far all fine, a SOAP fault is returned:

?xml version=1.0 encoding=UTF-8?
SOAP-ENV:Envelope 
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;SOAP-ENV:BodySOAP-ENV:FaultfaultcodeSOAP-ENV:Server/faultcodefaultstringSOAP-ERROR:
 Encoding: Violation of encoding 
rules/faultstring/SOAP-ENV:Fault/SOAP-ENV:Body/SOAP-ENV:Envelope

But if I submit an incomplete record no errors are returned:

?xml version=1.0 encoding=UTF-8?
soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
  soap:Body
product
  titleProduct name/title
/product
  /soap:Body
/soap:Envelope

The server callback function is called with the following arguments:

array(1) {
  [0]=
  object(stdClass)#2 (1) {
[title]=
string(12) Product name
  }
}

But I'd expect another encoding violation fault, because there was NOT 
minOccurs=0 in Product's id element definition. Am I doing something wrong?

Thank you

-- 
Giovanni Giacobbi

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

[PHP-DEV] 4.3.2RC4: patch for php.ini-dist and php.ini-recommended

[Giovanni Giacobbi]

PHP version:  4.3.2RC4
PHP Bug Type: *General Issues
Bug description:  php.ini-dist and php.ini-recommended cleanup patch

There are various typos and differences between the to files mentioned in
the subject. I made a cleanup of that and I'd like to send you the patch
file, but i couldn't find an email address where to direct ready patches
for CVS. (maybe you should write it in the package documentation?)

Regards

-- 
Giovanni Giacobbi
--- php-4.3.2RC4/php.ini-dist.orig	Thu May  8 03:23:35 2003
+++ php-4.3.2RC4/php.ini-dist	Tue May 27 17:08:04 2003
@@ -67,7 +67,7 @@
 ; Enable the PHP scripting language engine under Apache.
 engine = On
 
-; Allow the ? tag.  Otherwise, only ?php and script tags are recognized.  
+; Allow the ? tag.  Otherwise, only ?php and script tags are recognized.
 ; NOTE: Using short tags should be avoided when developing applications or
 ; libraries that are meant for redistribution, or deployment on PHP
 ; servers which are not under your control, because short tags may not
@@ -99,18 +99,18 @@
 ; Setting any output handler automatically turns on output buffering.
 ; Note: People who wrote portable scripts should not depend on this ini
 ;   directive. Instead, explicitly set the output handler using ob_start().
-;   Using this ini directive may cause problems unless you know what script 
+;   Using this ini directive may cause problems unless you know what script
 ;   is doing.
 ; Note: You cannot use both mb_output_handler with ob_iconv_handler
-;   and you cannot use both ob_gzhandler and zlib.output_compression. 
+;   and you cannot use both ob_gzhandler and zlib.output_compression.
 ;output_handler =
 
 ; Transparent output compression using the zlib library
 ; Valid values for this option are 'off', 'on', or a specific buffer size
 ; to be used for compression (default is 4KB)
-; Note: Resulting chunk size may vary due to nature of compression. PHP 
-;   outputs chunks that are few hundreds bytes each as a result of 
-;   compression. If you prefer a larger chunk size for better 
+; Note: Resulting chunk size may vary due to nature of compression. PHP
+;   outputs chunks that are few hundreds bytes each as a result of
+;   compression. If you prefer a larger chunk size for better
 ;   performance, enable output_buffering in addition.
 ; Note: You need to use zlib.output_handler instead of the standard
 ;   output_handler, or otherwise the output will be corrupted.
@@ -133,7 +133,7 @@
 ; which should be instanciated.
 ; A warning appears if the specified function is not defined, or if the
 ; function doesn't include/implement the missing class.
-; So only set this entry, if you really want to implement such a 
+; So only set this entry, if you really want to implement such a
 ; callback-function.
 unserialize_callback_func=
 
@@ -153,6 +153,7 @@
 ; reference).
 allow_call_time_pass_reference = On
 
+;
 ; Safe Mode
 ;
 safe_mode = Off
@@ -166,7 +167,7 @@
 ; including files from this directory and its subdirectories.
 ; (directory must also be in include_path or full path must
 ; be used when including)
-safe_mode_include_dir =
+safe_mode_include_dir =
 
 ; When safe_mode is on, only executables located in the safe_mode_exec_dir
 ; will be allowed to be executed via the exec family of functions.
@@ -231,6 +232,7 @@
 max_input_time = 60	; Maximum amount of time each script may spend parsing request data
 memory_limit = 8M  ; Maximum amount of memory a script may consume (8MB)
 
+
 ;;
 ; Error handling and logging ;
 ;;
@@ -294,13 +296,13 @@
 ; line until ignore_repeated_source is set true.
 ignore_repeated_errors = Off
 
-; Ignore source of message when ignoring repeated messages. When this setting 
+; Ignore source of message when ignoring repeated messages. When this setting
 ; is On you will not log errors with repeated messages from different files or
 ; sourcelines.
 ignore_repeated_source = Off
 
 ; If this parameter is set to Off, then memory leaks will not be shown (on
-; stdout or in the log). This has only effect in a debug compile, and if 
+; stdout or in the log). This has only effect in a debug compile, and if
 ; error reporting includes E_WARNING in the allowed list
 report_memleaks = On
 
@@ -309,16 +311,16 @@
 
 ; Disable the inclusion of HTML tags in error messages.
 ;html_errors = Off
-  
-; If html_errors is set On PHP produces clickable error messages that direct 
+
+; If html_errors is set On PHP produces clickable error messages that direct
 ; to a page describing the error or function causing the error in detail.
-; You can download a copy of the PHP manual from http://www.php.net/docs.php 
+; You can download a copy of the PHP manual from http://www.php.net/docs.php
 ; and change docref_root to the base URL of your local copy including the
-; leading '/'. You must also specify the file extension being used including 
+; leading