php-general Digest 19 Sep 2013 11:35:54 -0000 Issue 8367
php-general Digest 19 Sep 2013 11:35:54 - Issue 8367 Topics (messages 322083 through 322092): Re: assign database result to iinput text box 322083 by: Maciek Sokolewicz 322091 by: ITN Network Re: high traffic websites 322084 by: Negin Nickparsa 322086 by: Sebastian Krebs 322087 by: Stuart Dallas 322088 by: Negin Nickparsa 322089 by: Camilo Sperberg 322090 by: Sebastian Krebs No MIME-Type in imap_fetch_overview() 322085 by: Domain nikha.org Apache's PHP handlers 322092 by: Arno Kuhl 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 -- ---BeginMessage--- On 18-9-2013 7:33, iccsi wrote: I have following html code to show my input text box and php to connect server and select result from database server. I would like to know how I can I use php to assign the value to my input text. Your help and information is great appreciated, Regards, Hi iccsi, first, look at http://www.php.net/mysql_fetch_array the example should help you. Once you have the value you're looking for in a variable, you simply assign insert it into the value property of your input element. Ie. you should have something like input type=text name=a id=b value=the variable containing your data Also please note that the mysql extension is deprecated; you are advised to switch to either PDO_MySQL or mysqli instead. - Tul ---End Message--- ---BeginMessage--- ?php $username = root; $password = myPassword; $hostname = localhost; //connection to the database $dbhandle = mysql_connect($hostname, $username, $password) or die(Unable to connect to MySQL); echo Connected to MySQLbr; //select a database to work with $selected = mysql_select_db(iccsimd,$dbhandle) or die(Could not select aerver); //execute the SQL query and return records $result = mysql_fetch_assoc(mysql_query(SELECT invid, invdate, note, amount FROM invheader)); ? INPUT type=text name=Mytxt id=MytextID value=?php echo $result['note'];? / Like Maciek mentioned, if this is a new project use PDO or MySQLi instead, else use a PDO wrapper for MySQL functions. On Wed, Sep 18, 2013 at 7:45 AM, Maciek Sokolewicz maciek.sokolew...@gmail.com wrote: On 18-9-2013 7:33, iccsi wrote: I have following html code to show my input text box and php to connect server and select result from database server. I would like to know how I can I use php to assign the value to my input text. Your help and information is great appreciated, Regards, Hi iccsi, first, look at http://www.php.net/mysql_**fetch_arrayhttp://www.php.net/mysql_fetch_arraythe example should help you. Once you have the value you're looking for in a variable, you simply assign insert it into the value property of your input element. Ie. you should have something like input type=text name=a id=b value=the variable containing your data Also please note that the mysql extension is deprecated; you are advised to switch to either PDO_MySQL or mysqli instead. - Tul -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ---End Message--- ---BeginMessage--- Thank you Camilo to be more in details,suppose the website has 80,000 users and each page takes 200 ms to be rendered and you have thousand hits in a second so we want to reduce the time of rendering. is there any way to reduce the rendering time? other thing is suppose they want to upload files simultaneously and the videos are in the website not on another server like YouTube and so streams are really consuming the bandwidth. Also,It is troublesome to get backups,when getting backups you have problem of lock backing up with bulk of data. Sincerely Negin Nickparsa On Wed, Sep 18, 2013 at 12:50 PM, Camilo Sperberg unrea...@gmail.comwrote: 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.
php-general Digest 20 Sep 2013 05:28:48 -0000 Issue 8368
php-general Digest 20 Sep 2013 05:28:48 - 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 -- ---BeginMessage--- - 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--- ---BeginMessage--- -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--- ---BeginMessage--- 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
[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
Re: [PHP] Apache's PHP handlers
- Original Message - From: Arno Kuhl a...@dotcontent.net To: php-general@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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Apache's PHP handlers
-Original Message- From: Ken Robinson [mailto:kenrb...@rbnsn.com] Sent: 19 September 2013 01:52 PM To: a...@dotcontent.net Cc: php-general@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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
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
Re: [PHP] Apache's PHP handlers
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-general@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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache's PHP handlers
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
Re: [PHP] Apache's PHP handlers
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
Re: [PHP] Apache's PHP handlers
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/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache's PHP handlers
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
[PHP] PHP 5.5.4 has been released
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
RE: [PHP] Apache's PHP handlers
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Static methods vs. plain functions
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?
Re: [PHP] high traffic websites
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.comwrote: 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
Re: [PHP] Static methods vs. plain functions
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
Re: [PHP] Static methods vs. plain functions
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.comwrote: 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
Re: [PHP] Static methods vs. plain functions
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Static methods vs. plain functions
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.comwrote: 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
RE: [PHP] Apache's PHP handlers
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
[PHP] PHP 5.4.20 released!
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
