php-general Digest 10 Feb 2013 06:57:53 -0000 Issue 8116
Topics (messages 320156 through 320179):
Re: Random 404 screens
320156 by: Andy McKenzie
320157 by: Jim Giner
320159 by: Geoff Shang
320160 by: Mike Mackintosh
Apache to serve RESTful requests using PHP
320158 by: AmirBehzad Eslami
320161 by: Bastien
320162 by: AmirBehzad Eslami
320163 by: Stuart Dallas
320175 by: tamouse mailing lists
320179 by: AmirBehzad Eslami
Is header() malfunction due to PHP5.3.3 -> 5.4.11 transition?
320164 by: Jonathan Eagle
320165 by: Matijn Woudt
320166 by: Stuart Dallas
320167 by: Tedd Sperling
320168 by: Jonathan Eagle
320169 by: Stuart Dallas
320170 by: Jonathan Eagle
320171 by: Jonathan Eagle
320172 by: Matijn Woudt
320173 by: Matijn Woudt
320174 by: Jonathan Eagle
320177 by: Matijn Woudt
newbie with imap_mail_move
320176 by: dealTek
320178 by: Adam Richardson
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 ---
On Sat, Feb 9, 2013 at 10:41 AM, Jim Giner <jim.gi...@albanyhandball.com> wrote:
> This is a tough one.
>
> Lately, my web pages are giving me some problems. Once a day or so one or
> more of my pages/scripts will give me a 404 error page saying my web page
> has timed out. Problem is that the page was just displayed. I click on a
> link, the page shows up, I click on a button on it to trigger some activity
> and voila! An error. I hit refresh and my page is back and things work ok.
>
> Some background. My pages/appls/development does not do much of anything
> other than record/display stuff from my dbs and show off some pics. Nothing
> fancy other than some js to enhance the viewing of these pages. No playing
> with anything time-related and very few cookies. So I don't have a clue as
> to what constitues a "web page timeout".
>
> Can anyone enlighten me as to what I should be looking for here? Or even if
> it is something I'm the cause of?
>
> For those who wish to experiment my site is jimginer dot net. Can't
> guarantee you'll get the error, but you might.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Smart money is that it's nothing to do with you; in my experience,
that's usually a network problem. It could be on your end (I'm seeing
that a lot more often now that I've moved to a new house, or it could
be a problem with the server's connection.
I just loaded your page half a dozen times in short succession, and it
was fine, so that makes me think it's likely to be at your end... or
somewhere between you and the server, you never know.
--- End Message ---
--- Begin Message ---
On 2/9/2013 11:21 AM, Andy McKenzie wrote:
Smart money is that it's nothing to do with you; in my experience,
that's usually a network problem. It could be on your end (I'm seeing
that a lot more often now that I've moved to a new house, or it could
be a problem with the server's connection.
I just loaded your page half a dozen times in short succession, and it
was fine, so that makes me think it's likely to be at your end... or
somewhere between you and the server, you never know.
Well I feel better about my work - but now I guess I have to investigate
if my home network is having a problem.
Thanks for taking the time.
--- End Message ---
--- Begin Message ---
On Sat, 9 Feb 2013, Jim Giner wrote:
Lately, my web pages are giving me some problems. Once a day or so one or
more of my pages/scripts will give me a 404 error page saying my web page has
timed out. Problem is that the page was just displayed. I click on a link,
the page shows up, I click on a button on it to trigger some activity and
voila! An error. I hit refresh and my page is back and things work ok.
Since someone mentioned network issues, I will ask this question.
Is it actually a "404" page? That is to say, does the string "404"
actually appear in the error document?
If it does, then this would rule out your home network, as 404 is a
response code returned by the webserver.
Geoff.
--- End Message ---
--- Begin Message ---
On Saturday, February 9, 2013 at 11:51 AM, Geoff Shang wrote:
> On Sat, 9 Feb 2013, Jim Giner wrote:
>
> > Lately, my web pages are giving me some problems. Once a day or so one or
> > more of my pages/scripts will give me a 404 error page saying my web page
> > has
> > timed out. Problem is that the page was just displayed. I click on a link,
> > the page shows up, I click on a button on it to trigger some activity and
> > voila! An error. I hit refresh and my page is back and things work ok.
> >
>
>
> Since someone mentioned network issues, I will ask this question.
>
> Is it actually a "404" page? That is to say, does the string "404"
> actually appear in the error document?
>
> If it does, then this would rule out your home network, as 404 is a
> response code returned by the webserver.
>
> Geoff.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
What about your HTTP server (Apache, nginx, lighttpd)? Is is overloaded or all
child-threads/workers busy?
--- End Message ---
--- Begin Message ---
Dear list,
We're a developing a PHP-driven web service with a RESTful API,
and we have a dedicated Linux server for that with 6GB of RAM.
Since this service will be used by many clients in a concurrent
manner, we'll face with a high-load on our web-server. But
web-services are different from web pages, for instance they
don't include images, or in this case we only serve JSON.
I'm wondering what are the recommended configurations for
the Apache web-server in these situations? Should we disable
keep-avlie? What about other directives? Apache is our
bottleneck, and we're trying to optimize it. Should we use nginx instead?
Please let me know your suggestions.
Thank you,
-behzad
--- End Message ---
--- Begin Message ---
Bastien Koert
On 2013-02-09, at 11:42 AM, AmirBehzad Eslami <behzad.esl...@gmail.com> wrote:
> Dear list,
>
> We're a developing a PHP-driven web service with a RESTful API,
> and we have a dedicated Linux server for that with 6GB of RAM.
>
> Since this service will be used by many clients in a concurrent
> manner, we'll face with a high-load on our web-server. But
> web-services are different from web pages, for instance they
> don't include images, or in this case we only serve JSON.
>
> I'm wondering what are the recommended configurations for
> the Apache web-server in these situations? Should we disable
> keep-avlie? What about other directives? Apache is our
> bottleneck, and we're trying to optimize it. Should we use nginx instead?
>
> Please let me know your suggestions.
>
> Thank you,
> -behzad
How much of that data is cachable? You're likely to get bigger performance
gains from caching frequent data.
Keep-alive at maybe 1 second.
But would need to know more about the app to be able to suggest more
Bastien
--- End Message ---
--- Begin Message ---
Bastein,
Response is unique per request, and not cachable. The app
fetches records from MySQL (say, templates), performs a
process on them, and returns the generated output as JSON.
We were thinking to use Redis to reduce queries against
MySQL, but still Apache will remain as our bottleneck.
On Sun, Feb 10, 2013 at 1:00 AM, Bastien <phps...@gmail.com> wrote:
>
>
> Bastien Koert
>
> On 2013-02-09, at 11:42 AM, AmirBehzad Eslami <behzad.esl...@gmail.com>
> wrote:
>
> > Dear list,
> >
> > We're a developing a PHP-driven web service with a RESTful API,
> > and we have a dedicated Linux server for that with 6GB of RAM.
> >
> > Since this service will be used by many clients in a concurrent
> > manner, we'll face with a high-load on our web-server. But
> > web-services are different from web pages, for instance they
> > don't include images, or in this case we only serve JSON.
> >
> > I'm wondering what are the recommended configurations for
> > the Apache web-server in these situations? Should we disable
> > keep-avlie? What about other directives? Apache is our
> > bottleneck, and we're trying to optimize it. Should we use nginx instead?
> >
> > Please let me know your suggestions.
> >
> > Thank you,
> > -behzad
>
> How much of that data is cachable? You're likely to get bigger performance
> gains from caching frequent data.
>
> Keep-alive at maybe 1 second.
>
> But would need to know more about the app to be able to suggest more
>
> Bastien
--- End Message ---
--- Begin Message ---
On 9 Feb 2013, at 16:42, AmirBehzad Eslami <behzad.esl...@gmail.com> wrote:
> We're a developing a PHP-driven web service with a RESTful API,
> and we have a dedicated Linux server for that with 6GB of RAM.
>
> Since this service will be used by many clients in a concurrent
> manner, we'll face with a high-load on our web-server. But
> web-services are different from web pages, for instance they
> don't include images, or in this case we only serve JSON.
>
> I'm wondering what are the recommended configurations for
> the Apache web-server in these situations? Should we disable
> keep-avlie? What about other directives? Apache is our
> bottleneck, and we're trying to optimize it. Should we use nginx instead?
I find it unlikely that Apache is your bottleneck, especially with a service
involving MySQL. How have you come to this conclusion?
I would personally recommend nginx + php-fpm over Apache + mod-php every time.
The pre-request memory footprint is massively reduced and I've seen nothing but
upsides since migrating most of my client's sites, and my own.
As far as keep-alive goes, how frequently will individual clients be accessing
the service? Are they likely to be using client software that supports
keep-alive? You basically want to weigh up the cost of potentially keeping the
connection open against the likelihood that the majority of clients will make
use of it for multiple requests. My gut reaction based on your description
would be to set it to 1 as suggested by Bastien so it has minimal impact while
still allowing clients who support it to be that bit more efficient.
Focus your optimisation efforts on MySQL. If the bulk of requests will be reads
you'll benefit from read-only slaves. If the data can be neatly sharded then
that's definitely worth investigating. When writing data get it as close to the
structure that will be needed when reading, including de-normalising it if
necessary.
If you are using joins to pull in extra data (i.e. IDs to a name or similar)
look at using Memcache for those, but make sure that when they're updated in
the DB they're also updated in Memcache. Do the DB query, get all the Memcache
keys you need a do a multi-get request. The other way to do this is to
de-normalise as discussed above, but that makes updating the data very
expensive (as every row needs to be updated). In my tests breaking it out to a
Memcache instance was far more efficient.
At the end of the day there will always be things you can do that are only
applicable to your service, but the general rule is to need to do as little as
possible to serve the data when it's requested, shifting as much of the work as
possible to when it is written (assuming a mostly-read service).
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Sat, Feb 9, 2013 at 12:21 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 9 Feb 2013, at 16:42, AmirBehzad Eslami <behzad.esl...@gmail.com> wrote:
>> We're a developing a PHP-driven web service with a RESTful API,
>> and we have a dedicated Linux server for that with 6GB of RAM.
> I would personally recommend nginx + php-fpm over Apache + mod-php every
> time. The pre-request memory footprint is massively reduced and I've seen
> nothing but upsides since migrating most of my client's sites, and my own.
+1 for nginx+php-fpm - the memory savings on this are incredible;
while I keep using Apache as a general purpose server, nginx+php-fpm
is really ideal for large scale php applications.
--- End Message ---
--- Begin Message ---
Stuart, thanks for your detailed response.
>> I find it unlikely that Apache is your bottleneck,
>> especially with a service involving MySQL.
>> How have you come to this conclusion?
Apache is the entry-point to our service, and I did a
benchmark with AB to see how it can handle concurrent
requests in a timely fashion. After a number of 50 concurrent
requests, the average "time per request" reached from less than
a second to 5 seconds.
On the other hand, the MySQL's slow_query_log was clear,
with long_query_time = 1.
Our MySQL database consists of less than 200 records,
distributed in normalized tables, yes, queries are making joins,
but the overall performance is OK.
>> As far as keep-alive goes, how frequently will individual
>> clients be accessing the service?
There are only "a few" clients that call the service. These clients
are PHP-driven web pages. Each page has its own unique ClickID
and a set of other unique parameters per user visit. These pages send
these parameters to the service using php-curl, and expect a generated
response to be returned. That's why I'm saying each request and
response is unique.
Whenever a user visits a web-page, there would be a call to the
web-service. At the moment, we don't know number of concurrent
visits. We're looking for a way to figure that out in Apache.
Is there a way to see if the requests are using the previously keep-alived
http channel? Because same client will send requests to the service,
and I'm curious to know if the Apache will allocate the already-opened
channel, or will create a new one?
>> If you are using joins to pull in extra data (i.e. IDs to a name
>> or similar) look at using Memcache for those, but make sure
>> that when they're updated in the DB they're also updated in Memcache.
Memcache or Redis, I'm going to add a caching layer between
MySQL and PHP, to store the de-normilized data.
I'm starting to learn more about nginx + php-fpm, thanks for
sharing your positive experience about this.
-behzad
--- End Message ---
--- Begin Message ---
I'm having a problem with a very straightforward routine; one that works
in one PHP installation but not on the other. The only difference that I
can see between the working version and the non-working version is that
the one that doesn't work is running on the later version of PHP. The
following basic log-in routine works fine on my personal development
server, running PHP 5.3.3, but doesn't work on the production server,
hosted by 1&1.com that is running PHP 5.4.11.
<?php
require_once('../includes/initialize.php'); //<== $session object
init'd and set to false
if(!$session->is_logged_in())
{
header("Location: login.php");
exit;
}
?>
login.php is in the same directory as the file that has this code at the
very top of the file.
Everything works as expected right up to the 'exit;' line.
* $session->is_logged_in() is false
* when tested immediately after the 'header("Loc...)' statement,
'headers_sent()' reports true.
* no error messages result (like: 'header already sent', etc.)
Instead of the program flow moving to 'login.php', the URL indicates
that the destination is the original file, except that the file is empty
- zero bytes. I've tried accessing the routine via three different
computers, all running different MS operating systems from XP to Win7
and they all behave identically. The behavior is also consistent
between browsers (i.e., FireFox, Chrome, and Windows Explorer).
I also did a $_SERVER variable dump immediately before and after the
'header(...' line, expecting to see a difference in at least one of the
'REDIRECT_*' elements, but both outputs where identical with the
exception that the $_SERVER ouput after the header statement was
executed was missing the following line:
["HTTP_CACHE_CONTROL"]=> "max-age=0"
It doesn't look relevant to me, but I include it to be thorough.
I looked through the PHP changelog pages, but I don't see mention of the
problem (of course, that might just be due to my ignorance). The ISP
for the production version of PHP indicated that I should come here for
help, so here I am.
Can anyone shed some light as to what is (or might be) going on?
Any help or guidance that can be offered will be greatly appreciated.
Jonathan
--- End Message ---
--- Begin Message ---
On Sat, Feb 9, 2013 at 8:00 PM, Jonathan Eagle <jeo...@attglobal.net> wrote:
>
>
> I'm having a problem with a very straightforward routine; one that works
> in one PHP installation but not on the other. The only difference that I
> can see between the working version and the non-working version is that
> the one that doesn't work is running on the later version of PHP. The
> following basic log-in routine works fine on my personal development
> server, running PHP 5.3.3, but doesn't work on the production server,
> hosted by 1&1.com that is running PHP 5.4.11.
>
> <?php
> require_once('../includes/initialize.php'); //<== $session object
> init'd and set to false
>
> if(!$session->is_logged_in())
> {
> header("Location: login.php");
> exit;
> }
> ?>
>
> login.php is in the same directory as the file that has this code at the
> very top of the file.
>
> Everything works as expected right up to the 'exit;' line.
> * $session->is_logged_in() is false
> * when tested immediately after the 'header("Loc...)' statement,
> 'headers_sent()' reports true.
> * no error messages result (like: 'header already sent', etc.)
>
> Instead of the program flow moving to 'login.php', the URL indicates
> that the destination is the original file, except that the file is empty
> - zero bytes. I've tried accessing the routine via three different
> computers, all running different MS operating systems from XP to Win7
> and they all behave identically. The behavior is also consistent
> between browsers (i.e., FireFox, Chrome, and Windows Explorer).
>
It seems like the header is not actually send, maybe because the headers
are already sent.
You can check what your server returned with the Developer tools in Chrome,
or Firebug in Firefox. It should have that header in its return, but I
doubt it's there.
>
> I also did a $_SERVER variable dump immediately before and after the
> 'header(...' line, expecting to see a difference in at least one of the
> 'REDIRECT_*' elements, but both outputs where identical with the
> exception that the $_SERVER ouput after the header statement was
> executed was missing the following line:
>
$_SERVER refers to headers that were send from client to server, the
redirect header you set is with the headers sent from server to client.
I would try a file like this first:
<?php
header("Location: login.php");
?>
and see if that works. Then you can investigate further.
- Matijn
--- End Message ---
--- Begin Message ---
On 9 Feb 2013, at 19:00, Jonathan Eagle <jeo...@attglobal.net> wrote:
> I'm having a problem with a very straightforward routine; one that works
> in one PHP installation but not on the other. The only difference that I
> can see between the working version and the non-working version is that
> the one that doesn't work is running on the later version of PHP. The
> following basic log-in routine works fine on my personal development
> server, running PHP 5.3.3, but doesn't work on the production server,
> hosted by 1&1.com that is running PHP 5.4.11.
>
> <?php
> require_once('../includes/initialize.php'); //<== $session object
> init'd and set to false
>
> if(!$session->is_logged_in())
> {
> header("Location: login.php");
> exit;
> }
> ?>
>
> login.php is in the same directory as the file that has this code at the
> very top of the file.
>
> Everything works as expected right up to the 'exit;' line.
> * $session->is_logged_in() is false
> * when tested immediately after the 'header("Loc...)' statement,
> 'headers_sent()' reports true.
> * no error messages result (like: 'header already sent', etc.)
>
> Instead of the program flow moving to 'login.php', the URL indicates
> that the destination is the original file, except that the file is empty
> - zero bytes. I've tried accessing the routine via three different
> computers, all running different MS operating systems from XP to Win7
> and they all behave identically. The behavior is also consistent
> between browsers (i.e., FireFox, Chrome, and Windows Explorer).
>
> I also did a $_SERVER variable dump immediately before and after the
> 'header(...' line, expecting to see a difference in at least one of the
> 'REDIRECT_*' elements, but both outputs where identical with the
> exception that the $_SERVER ouput after the header statement was
> executed was missing the following line:
>
> ["HTTP_CACHE_CONTROL"]=> "max-age=0"
>
> It doesn't look relevant to me, but I include it to be thorough.
>
> I looked through the PHP changelog pages, but I don't see mention of the
> problem (of course, that might just be due to my ignorance). The ISP
> for the production version of PHP indicated that I should come here for
> help, so here I am.
>
> Can anyone shed some light as to what is (or might be) going on?
>
> Any help or guidance that can be offered will be greatly appreciated.
Check the output buffering settings. You say no errors are displayed, but are
you sure that errors are set to be displayed?
You mention the headers_sent() result immediately after the header() function
call is true. If the header() function call had worked it would not be true, it
would be false. You have output being sent to the client before that header()
function call.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Feb 9, 2013, at 2:00 PM, Jonathan Eagle <jeo...@attglobal.net> wrote:
> I'm having a problem with a very straightforward routine;
Jonathan:
No offense to your routine, but you may want to review this:
http://sperling.com/php/authorization/log-on.php
If anyone finds an error, please post.
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
--- Begin Message ---
Stuart,
Thanks for getting back to me.... you were right - I had misread the
headers_sent() Return Value statement. When I went back and tested
it turns out that the 'initialize' routine is somehow prematurely
sending output out. So, now I have to figure out which of the ten
called routines and classes/objects in the initialize script are the
culprit.
I greatly appreciate the assistance,
Jonathan
On 2/9/2013 2:34 PM, Stuart Dallas wrote:
> On 9 Feb 2013, at 19:00, Jonathan Eagle <jeo...@attglobal.net> wrote:
>
>> I'm having a problem with a very straightforward routine; one that works
>> in one PHP installation but not on the other. The only difference that I
>> can see between the working version and the non-working version is that
>> the one that doesn't work is running on the later version of PHP. The
>> following basic log-in routine works fine on my personal development
>> server, running PHP 5.3.3, but doesn't work on the production server,
>> hosted by 1&1.com that is running PHP 5.4.11.
>>
>> <?php
>> require_once('../includes/initialize.php'); //<== $session object
>> init'd and set to false
>>
>> if(!$session->is_logged_in())
>> {
>> header("Location: login.php");
>> exit;
>> }
>> ?>
>>
>> login.php is in the same directory as the file that has this code at the
>> very top of the file.
>>
>> Everything works as expected right up to the 'exit;' line.
>> * $session->is_logged_in() is false
>> * when tested immediately after the 'header("Loc...)' statement,
>> 'headers_sent()' reports true.
>> * no error messages result (like: 'header already sent', etc.)
>>
>> Instead of the program flow moving to 'login.php', the URL indicates
>> that the destination is the original file, except that the file is empty
>> - zero bytes. I've tried accessing the routine via three different
>> computers, all running different MS operating systems from XP to Win7
>> and they all behave identically. The behavior is also consistent
>> between browsers (i.e., FireFox, Chrome, and Windows Explorer).
>>
>> I also did a $_SERVER variable dump immediately before and after the
>> 'header(...' line, expecting to see a difference in at least one of the
>> 'REDIRECT_*' elements, but both outputs where identical with the
>> exception that the $_SERVER ouput after the header statement was
>> executed was missing the following line:
>>
>> ["HTTP_CACHE_CONTROL"]=> "max-age=0"
>>
>> It doesn't look relevant to me, but I include it to be thorough.
>>
>> I looked through the PHP changelog pages, but I don't see mention of the
>> problem (of course, that might just be due to my ignorance). The ISP
>> for the production version of PHP indicated that I should come here for
>> help, so here I am.
>>
>> Can anyone shed some light as to what is (or might be) going on?
>>
>> Any help or guidance that can be offered will be greatly appreciated.
>
>
> Check the output buffering settings. You say no errors are displayed, but are
> you sure that errors are set to be displayed?
>
> You mention the headers_sent() result immediately after the header() function
> call is true. If the header() function call had worked it would not be true,
> it would be false. You have output being sent to the client before that
> header() function call.
>
> -Stuart
>
--- End Message ---
--- Begin Message ---
On 9 Feb 2013, at 21:00, Jonathan Eagle <jeo...@attglobal.net> wrote:
> Stuart,
>
> Thanks for getting back to me.... you were right - I had misread the
> headers_sent() Return Value statement. When I went back and tested
> it turns out that the 'initialize' routine is somehow prematurely
> sending output out. So, now I have to figure out which of the ten
> called routines and classes/objects in the initialize script are the
> culprit.
>
> I greatly appreciate the assistance,
The error message that should be being displayed tells you where output was
started. Check your error_reporting and display_errors settings to make sure
errors are being displayed and you should be able to save a lot of time.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
> On 2/9/2013 2:34 PM, Stuart Dallas wrote:
>> On 9 Feb 2013, at 19:00, Jonathan Eagle <jeo...@attglobal.net> wrote:
>>
>>> I'm having a problem with a very straightforward routine; one that works
>>> in one PHP installation but not on the other. The only difference that I
>>> can see between the working version and the non-working version is that
>>> the one that doesn't work is running on the later version of PHP. The
>>> following basic log-in routine works fine on my personal development
>>> server, running PHP 5.3.3, but doesn't work on the production server,
>>> hosted by 1&1.com that is running PHP 5.4.11.
>>>
>>> <?php
>>> require_once('../includes/initialize.php'); //<== $session object
>>> init'd and set to false
>>>
>>> if(!$session->is_logged_in())
>>> {
>>> header("Location: login.php");
>>> exit;
>>> }
>>> ?>
>>>
>>> login.php is in the same directory as the file that has this code at the
>>> very top of the file.
>>>
>>> Everything works as expected right up to the 'exit;' line.
>>> * $session->is_logged_in() is false
>>> * when tested immediately after the 'header("Loc...)' statement,
>>> 'headers_sent()' reports true.
>>> * no error messages result (like: 'header already sent', etc.)
>>>
>>> Instead of the program flow moving to 'login.php', the URL indicates
>>> that the destination is the original file, except that the file is empty
>>> - zero bytes. I've tried accessing the routine via three different
>>> computers, all running different MS operating systems from XP to Win7
>>> and they all behave identically. The behavior is also consistent
>>> between browsers (i.e., FireFox, Chrome, and Windows Explorer).
>>>
>>> I also did a $_SERVER variable dump immediately before and after the
>>> 'header(...' line, expecting to see a difference in at least one of the
>>> 'REDIRECT_*' elements, but both outputs where identical with the
>>> exception that the $_SERVER ouput after the header statement was
>>> executed was missing the following line:
>>>
>>> ["HTTP_CACHE_CONTROL"]=> "max-age=0"
>>>
>>> It doesn't look relevant to me, but I include it to be thorough.
>>>
>>> I looked through the PHP changelog pages, but I don't see mention of the
>>> problem (of course, that might just be due to my ignorance). The ISP
>>> for the production version of PHP indicated that I should come here for
>>> help, so here I am.
>>>
>>> Can anyone shed some light as to what is (or might be) going on?
>>>
>>> Any help or guidance that can be offered will be greatly appreciated.
>>
>>
>> Check the output buffering settings. You say no errors are displayed, but
>> are you sure that errors are set to be displayed?
>>
>> You mention the headers_sent() result immediately after the header()
>> function call is true. If the header() function call had worked it would not
>> be true, it would be false. You have output being sent to the client before
>> that header() function call.
>>
>> -Stuart
>>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
Matijn,
Thanks for the suggestion. Your suspicions were correct. I am now
tracking down the culprit.
Jonathan
On 2/9/2013 2:34 PM, Matijn Woudt wrote:
> On Sat, Feb 9, 2013 at 8:00 PM, Jonathan Eagle <jeo...@attglobal.net> wrote:
>
>>
>>
>> I'm having a problem with a very straightforward routine; one that works
>> in one PHP installation but not on the other. The only difference that I
>> can see between the working version and the non-working version is that
>> the one that doesn't work is running on the later version of PHP. The
>> following basic log-in routine works fine on my personal development
>> server, running PHP 5.3.3, but doesn't work on the production server,
>> hosted by 1&1.com that is running PHP 5.4.11.
>>
>> <?php
>> require_once('../includes/initialize.php'); //<== $session object
>> init'd and set to false
>>
>> if(!$session->is_logged_in())
>> {
>> header("Location: login.php");
>> exit;
>> }
>> ?>
>>
>> login.php is in the same directory as the file that has this code at the
>> very top of the file.
>>
>> Everything works as expected right up to the 'exit;' line.
>> * $session->is_logged_in() is false
>> * when tested immediately after the 'header("Loc...)' statement,
>> 'headers_sent()' reports true.
>> * no error messages result (like: 'header already sent', etc.)
>>
>> Instead of the program flow moving to 'login.php', the URL indicates
>> that the destination is the original file, except that the file is empty
>> - zero bytes. I've tried accessing the routine via three different
>> computers, all running different MS operating systems from XP to Win7
>> and they all behave identically. The behavior is also consistent
>> between browsers (i.e., FireFox, Chrome, and Windows Explorer).
>>
>
> It seems like the header is not actually send, maybe because the headers
> are already sent.
> You can check what your server returned with the Developer tools in Chrome,
> or Firebug in Firefox. It should have that header in its return, but I
> doubt it's there.
>
>>
>> I also did a $_SERVER variable dump immediately before and after the
>> 'header(...' line, expecting to see a difference in at least one of the
>> 'REDIRECT_*' elements, but both outputs where identical with the
>> exception that the $_SERVER ouput after the header statement was
>> executed was missing the following line:
>>
>
> $_SERVER refers to headers that were send from client to server, the
> redirect header you set is with the headers sent from server to client.
>
>
> I would try a file like this first:
>
> <?php
> header("Location: login.php");
> ?>
>
> and see if that works. Then you can investigate further.
>
> - Matijn
>
--- End Message ---
--- Begin Message ---
My 'display_errors' is "ON" and my 'error_reporting' is "22517". I'm
not sure what that means but it looks as if I should be getting error
messages somewhere.
Jonathan
On 2/9/2013 4:02 PM, Stuart Dallas wrote:
> On 9 Feb 2013, at 21:00, Jonathan Eagle <jeo...@attglobal.net> wrote:
>
>> Stuart,
>>
>> Thanks for getting back to me.... you were right - I had misread the
>> headers_sent() Return Value statement. When I went back and tested
>> it turns out that the 'initialize' routine is somehow prematurely
>> sending output out. So, now I have to figure out which of the ten
>> called routines and classes/objects in the initialize script are the
>> culprit.
>>
>> I greatly appreciate the assistance,
>
> The error message that should be being displayed tells you where output was
> started. Check your error_reporting and display_errors settings to make sure
> errors are being displayed and you should be able to save a lot of time.
>
> -Stuart
>
--- End Message ---
--- Begin Message ---
On Sat, Feb 9, 2013 at 9:59 PM, Tedd Sperling <t...@sperling.com> wrote:
> On Feb 9, 2013, at 2:00 PM, Jonathan Eagle <jeo...@attglobal.net> wrote:
>
> > I'm having a problem with a very straightforward routine;
>
>
> Jonathan:
>
> No offense to your routine, but you may want to review this:
>
> http://sperling.com/php/authorization/log-on.php
>
> If anyone finds an error, please post.
>
> Cheers,
>
> tedd
Well, I hope you're not actually storing passwords plain text in real life
examples.
Other than that, this method allows session hijacking.
- Matijn
--- End Message ---
--- Begin Message ---
On Sat, Feb 9, 2013 at 10:08 PM, Jonathan Eagle <jeo...@attglobal.net>wrote:
> My 'display_errors' is "ON" and my 'error_reporting' is "22517". I'm
> not sure what that means but it looks as if I should be getting error
> messages somewhere.
>
> Jonathan
>
>
Most likely they end up in the logs instead of the screen. Try check the
logs (on linux, they are usually in /var/log/apache).
A general note (this also applies to tedd):
The HTTP specification notes that the Location header should be followed by
an absolute URI only. Even though probably every browser accepts relative
URIs too, it's incorrect. You should replace it with
http://myserver.com/login.php, or preferable, https://myserver.com/login.php
.
- Matijn
--- End Message ---
--- Begin Message ---
> Most likely they end up in the logs instead of the screen. Try check
> the logs (on linux, they are usually in /var/log/apache).
This is being hosted on 1and1.com, so I don't think I direct access to
those directories, but I have found a 'logs' folder off of the root.
Looking through that I see what seems to be a bunch of error log files.
I will look through those and see what I can find.
Thanks again,
Jonathan
,
On 2/9/2013 4:14 PM, Matijn Woudt wrote:
> On Sat, Feb 9, 2013 at 10:08 PM, Jonathan Eagle <jeo...@attglobal.net>wrote:
>
>> My 'display_errors' is "ON" and my 'error_reporting' is "22517". I'm
>> not sure what that means but it looks as if I should be getting error
>> messages somewhere.
>>
>> Jonathan
>>
>>
> Most likely they end up in the logs instead of the screen. Try check the
> logs (on linux, they are usually in /var/log/apache).
>
>
> A general note (this also applies to tedd):
> The HTTP specification notes that the Location header should be followed by
> an absolute URI only. Even though probably every browser accepts relative
> URIs too, it's incorrect. You should replace it with
> http://myserver.com/login.php, or preferable, https://myserver.com/login.php
> .
>
> - Matijn
>
--- End Message ---
--- Begin Message ---
On Sun, Feb 10, 2013 at 12:19 AM, Stephen <stephe...@rogers.com> wrote:
> On 13-02-09 04:11 PM, Matijn Woudt wrote:
>
>> On Sat, Feb 9, 2013 at 9:59 PM, Tedd Sperling <t...@sperling.com> wrote:
>>
>>
>> Jonathan:
>>
>> No offense to your routine, but you may want to review this:
>>
>> http://sperling.com/php/**authorization/log-on.php<http://sperling.com/php/authorization/log-on.php>
>>
>> If anyone finds an error, please post.
>>
>> Cheers,
>>
>> tedd
>>
>> Well, I hope you're not actually storing passwords plain text in real life
>> examples.
>> Other than that, this method allows session hijacking.
>>
>> - Matijn
>>
>> Can you explain how a session could be hijacked?
>
> Thank you!
>
> --
> Stephen
>
>
Sure,
Just basic session stuff first:
When you start a session, PHP sends a cookie header in return to the
client. This cookie header includes a session id. On next requests your
browser will send this same session id back to the server. Now the server
knows which session belongs to this client.
Now to the session hijack stuff:
I assume we are on a normal http server (not https), then this session id
will be send plain text in the http headers. Now, assume we are both
connected to a hotspot, then I will be able to read all traffic that passes
on to this hotspot, a so called man-in-the-middle attack. Once you have
logged in, I can get the cookie that contains the session id. Now I can
request the private part if I send that same cookie with it.
There are more forms of this attack, but they are more complicated. An SSL
secured connection solves most, but even with https, it is possible to do
this kind of attack.
For more info I'd like to refer to google;)
- Matijn
--- End Message ---
--- Begin Message ---
Hi all,
I'm a newbie with imap_mail_move
trying to open the INBOX and move all mail to LEGACY folder box.... (got this
code from the net)
it shows these errors... any idea how to fix this....?
---------------
Warning: reset() [function.reset]: Passed variable is not an array or object in
/home/bbeast/public_html/emtest/em-move.php on line 91
Warning: implode() [function.implode]: Invalid arguments passed in
/home/bbeast/public_html/emtest/em-move.php on line 92
Notice: Unknown: Error in IMAP command received by server. (errflg=2) in
Unknown on line 0
-------
<?php
$host1='{mail.xxx.com:993/ssl/novalidate-cert}INBOX';
$user='xxx';
$pass='xxx';
$mbox=@imap_open($host1,$user,$pass) or die("Can't connect: " .
imap_last_error());
$mbox_name = "INBOX";
$newmbox_name = "LEGACY";
if ($mbox_name != $newmbox_name) {
reset($msg_no);
$messageset = implode (",",$msg_no);
imap_mail_move($mbox,$messageset,$newmbox_name);
imap_expunge($mbox);
}
imap_close($mbox);
?>
--
Thanks,
Dave - DealTek
deal...@gmail.com
[db-3]
--- End Message ---
--- Begin Message ---
On Sat, Feb 9, 2013 at 7:29 PM, dealTek <deal...@gmail.com> wrote:
>
> Warning: reset() [function.reset]: Passed variable is not an array or
> object in /home/bbeast/public_html/emtest/em-move.php on line 91
>
> if ($mbox_name != $newmbox_name) {
> reset($msg_no);
> $messageset = implode (",",$msg_no);
> imap_mail_move($mbox,$messageset,$newmbox_name);
> imap_expunge($mbox);
> }
>
Where is the variable $msg_no coming from?
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
