php-general Digest 20 Sep 2013 05:28:48 -0000 Issue 8368
Topics (messages 322093 through 322110):
Re: Apache's PHP handlers
322093 by: Design in Motion Webdesign
322094 by: Arno Kuhl
322095 by: Arno Kuhl
322096 by: Design in Motion Webdesign
322097 by: Stuart Dallas
322098 by: Aziz Saleh
322099 by: Stuart Dallas
322100 by: Bastien Koert
322101 by: Arno Kuhl
322109 by: Ashley Sheridan
PHP 5.5.4 has been released
322102 by: Julien Pauli
Static methods vs. plain functions
322103 by: Simon Dániel
322105 by: Sebastian Krebs
322106 by: Aziz Saleh
322107 by: Paul M Foster
322108 by: Sebastian Krebs
Re: high traffic websites
322104 by: Negin Nickparsa
PHP 5.4.20 released!
322110 by: Stas Malyshev
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
----- Original Message -----
From: "Arno Kuhl" <a...@dotcontent.net>
To: <php-gene...@lists.php.net>
Sent: Thursday, September 19, 2013 1:35 PM
Subject: [PHP] Apache's PHP handlers
For the past week I've been trying to get to the bottom of an exploit, but
googling hasn't been much help so far, nor has my service provider.
Basically a file was uploaded with the filename xxx.php.pgif which
contained
nasty php code, and then the file was run directly from a browser. The
upload script used to upload this file checks that the upload filename
doesn't have a .php extension, which in this case it doesn't, so let it
through. I was under the impression apache would serve any file with an
extension not listed in its handlers directly back to the browser, but
instead it sent it to the php handler. Is this normal behaviour or is
there
a problem with my service provider's apache configuration? Trying this on
my
localhost returns the file contents directly to the browser as expected
and
doesn't run the php code.
Cheers
Arno
Arno,
the php file hidden as a gif will indeed not execute if opened directly from
your website. But if opened from a page hosted elsewhere with some code like
require($path_to_your_image), the php code inside the image will be sent to
the php handler and will be executed.
Prevention is the best way to avoid hacking from image upload. Check the
file extention and the file content before upload.
Cheers.
Steven
--- End Message ---
--- Begin Message ---
-----Original Message-----
From: Ken Robinson [mailto:kenrb...@rbnsn.com]
Sent: 19 September 2013 01:52 PM
To: <a...@dotcontent.net>
Cc: <php-gene...@lists.php.net>
Subject: Re: [PHP] Apache's PHP handlers
Check you .htaccess file. The hackers could have modified it to allow that
type of file to be executed. I had some that modified my .htaccess file to
go to a spam site when my site got a 404 error. That was nasty.
Ken
Sent from my iPad
On Sep 19, 2013, at 7:35 AM, "Arno Kuhl" <a...@dotcontent.net> wrote:
> For the past week I've been trying to get to the bottom of an exploit,
> but googling hasn't been much help so far, nor has my service provider.
> Basically a file was uploaded with the filename xxx.php.pgif which
> contained nasty php code, and then the file was run directly from a
> browser. The upload script used to upload this file checks that the
> upload filename doesn't have a .php extension, which in this case it
> doesn't, so let it through. I was under the impression apache would
> serve any file with an extension not listed in its handlers directly
> back to the browser, but instead it sent it to the php handler. Is
> this normal behaviour or is there a problem with my service provider's
> apache configuration? Trying this on my localhost returns the file
> contents directly to the browser as expected and doesn't run the php code.
>
>
>
> Cheers
>
> Arno
> S
Hi Ken, .htaccess wasn't modified, this file was just uploaded and run. So
far all my service provider has told me is it was because the filename
contained ".php" in the filename, even though it's not the extension, and
that's the reason apache sent it to the php handler. I'm sure that can't be
right, otherwise it would be open to all sorts of exploits.
Cheers
Arno
--- End Message ---
--- Begin Message ---
> For the past week I've been trying to get to the bottom of an exploit, but
> googling hasn't been much help so far, nor has my service provider.
> Basically a file was uploaded with the filename xxx.php.pgif which
contained
> nasty php code, and then the file was run directly from a browser. The
> upload script used to upload this file checks that the upload filename
> doesn't have a .php extension, which in this case it doesn't, so let it
> through. I was under the impression apache would serve any file with an
> extension not listed in its handlers directly back to the browser, but
> instead it sent it to the php handler. Is this normal behaviour or is
there
> a problem with my service provider's apache configuration? Trying this on
> my localhost returns the file contents directly to the browser as expected
> and doesn't run the php code.
--
Arno,
the php file hidden as a gif will indeed not execute if opened directly from
your website. But if opened from a page hosted elsewhere with some code like
require($path_to_your_image), the php code inside the image will be sent to
the php handler and will be executed.
Prevention is the best way to avoid hacking from image upload. Check the
file extention and the file content before upload.
Cheers.
Steven
--
Hi Steven, I agree the best way to avoid this is for the file upload script
to check the file contents and that's something I'll have to sort out,
currently it just checks the extension. But it's still a concern that a file
with any arbitrary extension can be processed as php script as long as it
has the text ".php" in the filename. I'm not worried about including the
file because that would require pre-existing malicious php code, I want to
prevent that malicious php code from running in the first place.
Cheers
Arno
--- End Message ---
--- Begin Message ---
Hi Arno,
it has nothing to do with ".php" in the file name. What the hacker did, was
uploading a .gif file with some malicious php code included to your
webserver. Then he called the .gif file from his own website by using a php
script containing some code like
require_once('http://www.yoursite.com/images/yourimage.gif'). At that moment
the php code inside the .gif file has been executed.
Steven
----- Original Message -----
From: "Arno Kuhl" <a...@dotcontent.net>
To: "'Design in Motion Webdesign'" <i...@designinmotion.be>;
<php-gene...@lists.php.net>
Sent: Thursday, September 19, 2013 2:43 PM
Subject: RE: [PHP] Apache's PHP handlers
For the past week I've been trying to get to the bottom of an exploit,
but
googling hasn't been much help so far, nor has my service provider.
Basically a file was uploaded with the filename xxx.php.pgif which
contained
nasty php code, and then the file was run directly from a browser. The
upload script used to upload this file checks that the upload filename
doesn't have a .php extension, which in this case it doesn't, so let it
through. I was under the impression apache would serve any file with an
extension not listed in its handlers directly back to the browser, but
instead it sent it to the php handler. Is this normal behaviour or is
there
a problem with my service provider's apache configuration? Trying this on
my localhost returns the file contents directly to the browser as
expected
and doesn't run the php code.
--
Arno,
the php file hidden as a gif will indeed not execute if opened directly
from
your website. But if opened from a page hosted elsewhere with some code
like
require($path_to_your_image), the php code inside the image will be sent
to
the php handler and will be executed.
Prevention is the best way to avoid hacking from image upload. Check the
file extention and the file content before upload.
Cheers.
Steven
--
Hi Steven, I agree the best way to avoid this is for the file upload
script
to check the file contents and that's something I'll have to sort out,
currently it just checks the extension. But it's still a concern that a
file
with any arbitrary extension can be processed as php script as long as it
has the text ".php" in the filename. I'm not worried about including the
file because that would require pre-existing malicious php code, I want to
prevent that malicious php code from running in the first place.
Cheers
Arno
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On 19 Sep 2013, at 13:58, "Design in Motion Webdesign" <i...@designinmotion.be>
wrote:
> it has nothing to do with ".php" in the file name. What the hacker did, was
> uploading a .gif file with some malicious php code included to your
> webserver. Then he called the .gif file from his own website by using a php
> script containing some code like
> require_once('http://www.yoursite.com/images/yourimage.gif'). At that moment
> the php code inside the .gif file has been executed.
In possibly the most pointless way ever! In that scenario the script would be
executed on the "hacker"'s server (assuming Apache is set up correctly), so
there's no point in her managing to put it on your server at all!
Arno: If you can request that file using a web browser, and it gets executed as
PHP on your server then there is an error in the Apache configuration.
Easy test: create a file in a text editor containing some PHP (<?php phpinfo();
?> would be enough) and upload it to the www root of your site and name it
test.pgif. Then hit http://www.yourdomain.com/test.pgif in your browser. If you
see the PHP code or an error then you're fine. If you see PHP's info page then
you need to change web host as quickly as possible. I don't care if they fix it
- the fact their server was configured to do this by default is enough for me
to never trust them again.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
The best way to handle file uploads is to:
1) Store the filename somewhere in the DB, rename the file to a random
string without extension and store the mapping in the DB as well.
2) When sending the file, set the header content to the filename and output
the content of the file via PHP (ex: by readfile).
Aziz
This way even if the file is PHP code, it will be of no issue to you.
On Thu, Sep 19, 2013 at 9:05 AM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 19 Sep 2013, at 13:58, "Design in Motion Webdesign" <
> i...@designinmotion.be> wrote:
>
> > it has nothing to do with ".php" in the file name. What the hacker did,
> was uploading a .gif file with some malicious php code included to your
> webserver. Then he called the .gif file from his own website by using a php
> script containing some code like require_once('
> http://www.yoursite.com/images/yourimage.gif'). At that moment the php
> code inside the .gif file has been executed.
>
> In possibly the most pointless way ever! In that scenario the script would
> be executed on the "hacker"'s server (assuming Apache is set up correctly),
> so there's no point in her managing to put it on your server at all!
>
> Arno: If you can request that file using a web browser, and it gets
> executed as PHP on your server then there is an error in the Apache
> configuration.
>
> Easy test: create a file in a text editor containing some PHP (<?php
> phpinfo(); ?> would be enough) and upload it to the www root of your site
> and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in
> your browser. If you see the PHP code or an error then you're fine. If you
> see PHP's info page then you need to change web host as quickly as
> possible. I don't care if they fix it - the fact their server was
> configured to do this by default is enough for me to never trust them again.
>
> -Stuart
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
On 19 Sep 2013, at 14:39, Aziz Saleh <azizsa...@gmail.com> wrote:
> The best way to handle file uploads is to:
>
> 1) Store the filename somewhere in the DB, rename the file to a random string
> without extension and store the mapping in the DB as well.
> 2) When sending the file, set the header content to the filename and output
> the content of the file via PHP (ex: by readfile).
>
> Aziz
>
> This way even if the file is PHP code, it will be of no issue to you.
What you describe it highly inefficient, clunky, and unnecessary. You've
managed to get PHP and a database involved in serving a static file, for no
reason other than to avoid fixing the web server configuration.
A misconfigured web server should be fixed, not worked around.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Thursday, September 19, 2013, Stuart Dallas wrote:
> On 19 Sep 2013, at 14:39, Aziz Saleh <azizsa...@gmail.com <javascript:;>>
> wrote:
>
> > The best way to handle file uploads is to:
> >
> > 1) Store the filename somewhere in the DB, rename the file to a random
> string without extension and store the mapping in the DB as well.
> > 2) When sending the file, set the header content to the filename and
> output the content of the file via PHP (ex: by readfile).
> >
> > Aziz
> >
> > This way even if the file is PHP code, it will be of no issue to you.
>
> What you describe it highly inefficient, clunky, and unnecessary. You've
> managed to get PHP and a database involved in serving a static file, for no
> reason other than to avoid fixing the web server configuration.
>
> A misconfigured web server should be fixed, not worked around.
>
> -Stuart
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
You can also run a strip_tags() call on the file upload to help prevent this
Bastien
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
Arno: If you can request that file using a web browser, and it gets executed
as PHP on your server then there is an error in the Apache configuration.
Easy test: create a file in a text editor containing some PHP (<?php
phpinfo(); ?> would be enough) and upload it to the www root of your site
and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in your
browser. If you see the PHP code or an error then you're fine. If you see
PHP's info page then you need to change web host as quickly as possible. I
don't care if they fix it - the fact their server was configured to do this
by default is enough for me to never trust them again.
-Stuart
--
Thanks Stuart. I just tried it now, test.php.pgif displayed the info while
test.xyz.pgif returned the content, confirming the problem. My service
provider finally conceded the problem is on their side and are looking for
an urgent fix, much too complicated to consider moving service providers in
the short term.
As a side note, the sp said the issue is new and coincided with an upgrade
to fastcgi recently, I wonder if the hacker was exploiting a known issue
with that scenario?
Cheers
Arno
--- End Message ---
--- Begin Message ---
On Thu, 2013-09-19 at 16:14 +0200, Arno Kuhl wrote:
> Arno: If you can request that file using a web browser, and it gets executed
> as PHP on your server then there is an error in the Apache configuration.
>
> Easy test: create a file in a text editor containing some PHP (<?php
> phpinfo(); ?> would be enough) and upload it to the www root of your site
> and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in your
> browser. If you see the PHP code or an error then you're fine. If you see
> PHP's info page then you need to change web host as quickly as possible. I
> don't care if they fix it - the fact their server was configured to do this
> by default is enough for me to never trust them again.
>
> -Stuart
> --
>
> Thanks Stuart. I just tried it now, test.php.pgif displayed the info while
> test.xyz.pgif returned the content, confirming the problem. My service
> provider finally conceded the problem is on their side and are looking for
> an urgent fix, much too complicated to consider moving service providers in
> the short term.
>
> As a side note, the sp said the issue is new and coincided with an upgrade
> to fastcgi recently, I wonder if the hacker was exploiting a known issue
> with that scenario?
>
> Cheers
> Arno
>
>
I think most importantly, validate your input!
If you're expecting an image, check to make sure it's an image. Use the
imagecopyresampled() function that's part of GD to create a duplicate of
the exact same size to ensure that it's both an image and not containing
a hidden payload (which has happened to JPEG images before)
If it's a file of another type, use a different appropriate method to
validate that. DOMDocument will deal with XML and HTML documents, you
can use zip functions to inspect Office documents (the newer types at
least), FPDF to handle PDF files, etc.
By only checking the extension you're relying on user-supplied data,
which by definition is tainted.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
Hi!
The PHP development team announces the immediate availability of PHP 5.5.4.
This release fixes several bugs against PHP 5.5.3.
All PHP users are encouraged to upgrade to this new version.
For source downloads of PHP 5.5.4 please visit our
downloads page:
http://www.php.net/downloads.php
Windows binaries can be found on:
http://windows.php.net/download/
The list of changes is recorded in the ChangeLog at:
http://www.php.net/ChangeLog-5.php#5.5.4
We would like to thank the contributors and the PHP community for making
this release available.
Regards,
Julien Pauli & David Soria Parra
--- End Message ---
--- Begin Message ---
Hi,
I am working on an OOP project, and cannot decide which way to follow when
I have to write a simple function.
For example, I want to write a function which generates a random string. In
an OOP environtment, it is a matter of course to create a static class and
a static method for that. But why? Isn't it more elegant, if I implement
such a simple thing as a plain function? Not to mention that a function is
more efficient than a class method.
So, in object-oriented programming, what is the best practice to implement
such a simple function?
--- End Message ---
--- Begin Message ---
2013/9/19 Simon Dániel <simondan...@gmail.com>
> Hi,
>
> I am working on an OOP project, and cannot decide which way to follow when
> I have to write a simple function.
>
> For example, I want to write a function which generates a random string. In
> an OOP environtment, it is a matter of course to create a static class and
> a static method for that. But why? Isn't it more elegant, if I implement
> such a simple thing as a plain function?
I'd say: Definitely!
> Not to mention that a function is
> more efficient than a class method.
>
Actually I wouldn't be so sure about that.
>
> So, in object-oriented programming, what is the best practice to implement
> such a simple function?
>
In "strict"-OOP [1] you would choose a static method, because functions are
simply forbidden. However, PHP isn't strict about that by itself. So I for
myself don't like the dogmatic "We use classes and nothing else!"-approach.
If a function fits better, it's OK to be a function.
[1] Actually that would end up in a mix of OOP and "class-oriented
programming", which isn't that strict.
--
github.com/KingCrunch
--- End Message ---
--- Begin Message ---
I think that it would be more elegant if you are already in a OOP to keep
the flow and stick to OOP. It just doesn't make sense to me in an
environment that uses OOP to have functions laying around.
Personally I like to group similar functionality together in their own
objects, this way I can reuse them on different projects, the random string
generator is an excellent example of something I usually use in almost all
of my projects.
Function calling is usually faster than object calling (depends on how you
benchmark it) since there is an overhead to it. There are some who tried to
"benchmark" this and had opposite results, It all comes down to how are you
going to use that functionality:
http://www.webhostingtalk.com/showthread.php?t=538076
http://www.micro-optimization.com/global-function-vs-static-method
Personally in my projects - specifically if I use a framework, I try to
stay away from making standalone functions unless absolutely necessary.
On Thu, Sep 19, 2013 at 12:44 PM, Sebastian Krebs <krebs....@gmail.com>wrote:
> 2013/9/19 Simon Dániel <simondan...@gmail.com>
>
> > Hi,
> >
> > I am working on an OOP project, and cannot decide which way to follow
> when
> > I have to write a simple function.
> >
> > For example, I want to write a function which generates a random string.
> In
> > an OOP environtment, it is a matter of course to create a static class
> and
> > a static method for that. But why? Isn't it more elegant, if I implement
> > such a simple thing as a plain function?
>
>
> I'd say: Definitely!
>
>
> > Not to mention that a function is
> > more efficient than a class method.
> >
>
> Actually I wouldn't be so sure about that.
>
>
> >
> > So, in object-oriented programming, what is the best practice to
> implement
> > such a simple function?
> >
>
> In "strict"-OOP [1] you would choose a static method, because functions are
> simply forbidden. However, PHP isn't strict about that by itself. So I for
> myself don't like the dogmatic "We use classes and nothing else!"-approach.
> If a function fits better, it's OK to be a function.
>
> [1] Actually that would end up in a mix of OOP and "class-oriented
> programming", which isn't that strict.
>
> --
> github.com/KingCrunch
>
--- End Message ---
--- Begin Message ---
On Thu, Sep 19, 2013 at 06:28:32PM +0200, Simon Dániel wrote:
> Hi,
>
> I am working on an OOP project, and cannot decide which way to follow when
> I have to write a simple function.
>
> For example, I want to write a function which generates a random string. In
> an OOP environtment, it is a matter of course to create a static class and
> a static method for that. But why? Isn't it more elegant, if I implement
> such a simple thing as a plain function? Not to mention that a function is
> more efficient than a class method.
>
> So, in object-oriented programming, what is the best practice to implement
> such a simple function?
"Best practices" are for academics and people who read Datamation.
You have to look at why OOP exists and then ask yourself if the function
you wish to create really needs any of the values that attend OOP. You
also have to look at how simple your code is to read and understand.
Based on what you've described, there would appear to be absolutely no
value in making it into a class with a static method. In that case, all
you would have done is to add an extra level of complexity to your code.
If I were a programmer coming in after you to work with your code, I'd
ask myself why in the world you did that. And if feasible, I would
change it back to a flat function for the sake of simplicity.
Always prefer non-OOP unless you have some compelling reason to make
something object-oriented. For example, the interface to a DBMS is
something which may involve many many functions. It is definitely
something which benefits from OOP code, not flat functions. I've
personally found that dates benefit from this same treatment.
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
2013/9/19 Aziz Saleh <azizsa...@gmail.com>
> I think that it would be more elegant if you are already in a OOP to keep
> the flow and stick to OOP. It just doesn't make sense to me in an
> environment that uses OOP to have functions laying around.
>
buzzword: multi-paradigm. Thats why it could make sense ;)
>
> Personally I like to group similar functionality together in their own
> objects,
>
- That aren't objects, but classes. Actually you don't programm in
object-oriented, but in class-oriented (or probably a mix)
- You can (imo "should") use namespaces
> this way I can reuse them on different projects, the random string
> generator is an excellent example of something I usually use in almost all
> of my projects.
>
> Function calling is usually faster than object calling (depends on how you
> benchmark it) since there is an overhead to it. There are some who tried to
> "benchmark" this and had opposite results, It all comes down to how are you
> going to use that functionality:
>
> http://www.webhostingtalk.com/showthread.php?t=538076
> http://www.micro-optimization.com/global-function-vs-static-method
>
> Personally in my projects - specifically if I use a framework, I try to
> stay away from making standalone functions unless absolutely necessary.
>
>
>
> On Thu, Sep 19, 2013 at 12:44 PM, Sebastian Krebs <krebs....@gmail.com>wrote:
>
>> 2013/9/19 Simon Dániel <simondan...@gmail.com>
>>
>> > Hi,
>> >
>> > I am working on an OOP project, and cannot decide which way to follow
>> when
>> > I have to write a simple function.
>> >
>> > For example, I want to write a function which generates a random
>> string. In
>> > an OOP environtment, it is a matter of course to create a static class
>> and
>> > a static method for that. But why? Isn't it more elegant, if I implement
>> > such a simple thing as a plain function?
>>
>>
>> I'd say: Definitely!
>>
>>
>> > Not to mention that a function is
>> > more efficient than a class method.
>> >
>>
>> Actually I wouldn't be so sure about that.
>>
>>
>> >
>> > So, in object-oriented programming, what is the best practice to
>> implement
>> > such a simple function?
>> >
>>
>> In "strict"-OOP [1] you would choose a static method, because functions
>> are
>> simply forbidden. However, PHP isn't strict about that by itself. So I for
>> myself don't like the dogmatic "We use classes and nothing
>> else!"-approach.
>> If a function fits better, it's OK to be a function.
>>
>> [1] Actually that would end up in a mix of OOP and "class-oriented
>> programming", which isn't that strict.
>>
>> --
>> github.com/KingCrunch
>>
>
>
--
github.com/KingCrunch
--- End Message ---
--- Begin Message ---
it may be helpful for someone.
I liked GTmetrix kinda helpful and magic. <http://gtmetrix.com/#!>
Sincerely
Negin Nickparsa
On Wed, Sep 18, 2013 at 4:42 PM, Sebastian Krebs <krebs....@gmail.com>wrote:
> 2013/9/18 Camilo Sperberg <unrea...@gmail.com>
>
> >
> > On Sep 18, 2013, at 14:26, Haluk Karamete <halukkaram...@gmail.com>
> wrote:
> >
> > >> I recommend OPCache, which is already included in PHP 5.5.
> > >
> > > Camilo,
> > > I'm just curious about the disadvantageous aspects of OPcache.
> > >
> > > My logic says there must be some issues with it otherwise it would
> have
> > come already enabled.
> > >
> > > Sent from iPhone
> > >
> > >
> > > On Sep 18, 2013, at 2:20 AM, Camilo Sperberg <unrea...@gmail.com>
> wrote:
> > >
> > >>
> > >> On Sep 18, 2013, at 09:38, Negin Nickparsa <nickpa...@gmail.com>
> wrote:
> > >>
> > >>> Thank you Sebastian..actually I will already have one if qualified
> for
> > the
> > >>> job. Yes, and I may fail to handle it that's why I asked for
> guidance.
> > >>> I wanted some tidbits to start over. I have searched through yslow,
> > >>> HTTtrack and others.
> > >>> I have searched through php list in my email too before asking this
> > >>> question. it is kind of beneficial for all people and not has been
> > asked
> > >>> directly.
> > >>>
> > >>>
> > >>> Sincerely
> > >>> Negin Nickparsa
> > >>>
> > >>>
> > >>> On Wed, Sep 18, 2013 at 10:45 AM, Sebastian Krebs <
> krebs....@gmail.com
> > >wrote:
> > >>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> 2013/9/18 Negin Nickparsa <nickpa...@gmail.com>
> > >>>>
> > >>>>> In general, what are the best ways to handle high traffic websites?
> > >>>>>
> > >>>>> VPS(clouds)?
> > >>>>> web analyzers?
> > >>>>> dedicated servers?
> > >>>>> distributed memory cache?
> > >>>>>
> > >>>>
> > >>>> Yes :)
> > >>>>
> > >>>> But seriously: That is a topic most of us spent much time to get
> into
> > it.
> > >>>> You can explain it with a bunch of buzzwords. Additional, how do you
> > define
> > >>>> "high traffic websites"? Do you already _have_ such a site? Or do
> you
> > >>>> _want_ it? It's important, because I've seen it far too often, that
> > >>>> projects spent too much effort in their "high traffic
> infrastructure"
> > and
> > >>>> at the end it wasn't that high traffic ;) I wont say, that you
> cannot
> > be
> > >>>> successfull, but you should start with an effort you can handle.
> > >>>>
> > >>>> Regards,
> > >>>> Sebastian
> > >>>>
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>> Sincerely
> > >>>>> Negin Nickparsa
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> github.com/KingCrunch
> > >>>>
> > >>
> > >> Your question is way too vague to be answered properly... My best
> guess
> > would be that it depends severely on the type of website you have and
> how's
> > the current implementation being well... implemented.
> > >>
> > >> Simply said: what works for Facebook may/will not work for linkedIn,
> > twitter or Google, mainly because the type of search differs A LOT:
> > facebook is about relations between people, twitter is about small pieces
> > of data not mainly interconnected between each other, while Google is all
> > about links and all type of content: from little pieces of information
> > through whole Wikipedia.
> > >>
> > >> You could start by studying how varnish and redis/memcached works, you
> > could study about how proxies work (nginx et al), CDNs and that kind of
> > stuff, but if you want more specific answers, you could better ask
> specific
> > question.
> > >>
> > >> In the PHP area, an opcode cache does the job very well and can
> > accelerate the page load by several orders of magnitude, I recommend
> > OPCache, which is already included in PHP 5.5.
> > >>
> > >> Greetings.
> > >>
> > >>
> > >> --
> > >> PHP General Mailing List (http://www.php.net/)
> > >> To unsubscribe, visit: http://www.php.net/unsub.php
> > >>
> >
> >
> > The original RFC states:
> >
> > https://wiki.php.net/rfc/optimizerplus
> > The integration proposed for PHP 5.5.0 is mostly 'soft' integration. That
> > means that there'll be no tight coupling between Optimizer+ and PHP;
> Those
> > who wish to use another opcode cache will be able to do so, by not
> loading
> > Optimizer+ and loading another opcode cache instead. As per the Suggested
> > Roadmap above, we might want to review this decision in the future; There
> > might be room for further performance or functionality gains from tighter
> > integration; None are known at this point, and they're beyond the scope
> of
> > this RFC.
> >
> > So that's why OPCache isn't enabled by default in PHP 5.5
> >
>
>
> Also worth to mention, that it is the first release with an opcode-cache
> integrated. Giving the other some release to get used to it, sounds useful
> :)
>
>
> >
> > Greetings.
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> github.com/KingCrunch
>
--- End Message ---
--- Begin Message ---
Hello!
The PHP development team announces the immediate availability of PHP
5.4.20. About 30 bugs were fixed. All users of PHP 5.4 are encouraged to
upgrade to this release.
For source downloads of PHP 5.4.20 please visit our
downloads page: http://www.php.net/downloads.php
Windows binaries can be found on windows.php.net/download/
The list of changes are recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.4.20
Stanislav Malyshev
PHP 5.4 Release Master
--- End Message ---
