php-general Digest 27 Aug 2011 04:59:43 -0000 Issue 7457

Topics (messages 314619 through 314630):

Re: Dreaded Premature end of script headers
        314619 by: Richard Riley
        314620 by: Stuart Dallas
        314621 by: John Black
        314622 by: tamouse mailing lists
        314623 by: tamouse mailing lists
        314624 by: tamouse mailing lists
        314625 by: tamouse mailing lists
        314626 by: tamouse mailing lists
        314627 by: Geoff Shang
        314628 by: tamouse mailing lists
        314629 by: tamouse mailing lists
        314630 by: Camilo Sperberg

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 ---
tamouse mailing lists <tamouse.li...@gmail.com> writes:

> I'm encountering this on a script, but I can't figure out where it's
> actually failing. How do I debug this problem???

Depends on what you mean by "script". Do a binary search with a php line
that says "I got here".


--- End Message ---
--- Begin Message ---
On 26 Aug 2011, at 06:56, tamouse mailing lists wrote:

> I'm encountering this on a script, but I can't figure out where it's
> actually failing. How do I debug this problem???

Make sure you have error_reporting set to E_ALL and display_errors on in your 
php.ini. A script that stops unexpectedly is almost certainly due to a fatal 
error, and if you're not seeing the error message because either of those 
settings are not set to display them, you're coding blind!

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

--- End Message ---
--- Begin Message ---
On 26.08.2011 07:56, tamouse mailing lists wrote:
I'm encountering this on a script, but I can't figure out where it's
actually failing. How do I debug this problem???


What does you log say?
Make sure that you turn error reporting on and crank up the info it spits out.

I always develop with:
display_errors = On
error_reporting = E_ALL | E_STRICT

also make sure that
output_buffering = Off
or you will not see some error.

Looks like someone was faster ;(

--- End Message ---
--- Begin Message ---
On Fri, Aug 26, 2011 at 2:17 AM, Кирилл <bestestm...@gmail.com> wrote:
> Actually i think you outputing something in script, before you use headers -
> there are several solutions:
> 1)make your headers functions at the top of your script
> 2)if there is no any output - you should look for invisible characters like
> BOM or new line
> 3)use ob_start() at the beginning and ob_end_flush() at the end - it will
> buffer all output
> P.S. If i wanna know what headers come from script i use these steps at
> Chrome push combination (ctrl + shift + j) click on Network tab, reload
> page, find something with the name of your page click on it, and see script
> headers at headers tab

That's what I thought as well, however, the script itself doesn't emit
any headers. And usually, if output is send before a script emits
headers, you get an entirely different error. Under normal
circumstances, the script just outputs a couple of lines to show
status. This script is run as a cron job nightly and the output is
just appended to a log. What's getting appended instead is a 500 error
message. If i run the script with debugging enabled (which will emit a
whole lot of output), the premature end of script headers error
doesn't occur.

--- End Message ---
--- Begin Message ---
On Fri, Aug 26, 2011 at 7:41 AM, David Robley <robl...@aapt.net.au> wrote:
> tamouse mailing lists wrote:
>
>> I'm encountering this on a script, but I can't figure out where it's
>> actually failing. How do I debug this problem???
>
> Look first for unclosed curly braces {}

The script passes all syntax checks.

>
> You might find it useful to try an editor that does bracket matching and
> highlighting as an aid to finding the offending code.

I'm using TextMate which does this admirably well.

--- End Message ---
--- Begin Message ---
On Fri, Aug 26, 2011 at 8:03 AM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 26 Aug 2011, at 06:56, tamouse mailing lists wrote:
>
>> I'm encountering this on a script, but I can't figure out where it's
>> actually failing. How do I debug this problem???
>
> Make sure you have error_reporting set to E_ALL and display_errors on in your 
> php.ini. A script that stops unexpectedly is almost certainly due to a fatal 
> error, and if you're not seeing the error message because either of those 
> settings are not set to display them, you're coding blind!

When I turn on debugging, it sets these up. However, then the script
works perfectly.

--- End Message ---
--- Begin Message ---
On Fri, Aug 26, 2011 at 8:06 AM, John Black
<s...@network-technologies.org> wrote:
> On 26.08.2011 07:56, tamouse mailing lists wrote:
>>
>> I'm encountering this on a script, but I can't figure out where it's
>> actually failing. How do I debug this problem???
>>
>
> What does you log say?

The log says what I said: Premature end of script headers <filename>


> Make sure that you turn error reporting on and crank up the info it spits
> out.

When I turn on my debugging for the script, it sets error_reporting
and display_errors, and emits a lot of debug info. However, the script
doesn't fail when that is set.



> I always develop with:
> display_errors = On
> error_reporting = E_ALL | E_STRICT

This script is in production, and just started failing. What's changed
is data in the database which affects the execution of the script.
Note that it does not fail in the development, test or staging
environments.

--- End Message ---
--- Begin Message ---
On Fri, Aug 26, 2011 at 7:59 AM, Richard Riley <rile...@googlemail.com> wrote:
> tamouse mailing lists <tamouse.li...@gmail.com> writes:
>
>> I'm encountering this on a script, but I can't figure out where it's
>> actually failing. How do I debug this problem???
>
> Depends on what you mean by "script".

By script, I mean php script that runs from fastcgi with a .php extension....

> Do a binary search with a php line
> that says "I got here".

If it was a straight-line script, that might work, but it's a loop. As
soon as anything is emitted, the script works.

--- End Message ---
--- Begin Message ---
On Fri, 26 Aug 2011, tamouse mailing lists wrote:

The log says what I said: Premature end of script headers <filename>

I put this into Google and got this: http://htmlfixit.com/cgi-tutes/tutorial_Common_Web_dev_error_messages_and_what_they_mean.php#premature

As I understand it, the webserver is complaining that it did not get all the headers it expected from the script before it terminated.

Given that you say this is for a cron job, the script may well be doing exactly what you want it to do, but it's not outputting anything which is why you get an error.

Presumably, you are calling this cron job with some process which runs the PHP script through a URL on your webserver.

To fix this, I'd suggest one of the following.  Either:

1. Modify the script so that it does actually output something, thereby making the error go away.

or

2. Run the script directly with PHP instead of via your webserver. E.g.: php -f <yourscriptname>

IMHO, 2 would be the better way to go if you can do this.

HTH,
Geoff.


--- End Message ---
--- Begin Message ---
On Fri, Aug 26, 2011 at 1:42 PM, Geoff Shang <ge...@quitelikely.com> wrote:
> I put this into Google and got this:
> http://htmlfixit.com/cgi-tutes/tutorial_Common_Web_dev_error_messages_and_what_they_mean.php#premature


Yeah, I saw that too. I do know the mechanism that is happening. I
just can't figure out where the problem is without inserting print
statements.

> Presumably, you are calling this cron job with some process which runs the
> PHP script through a URL on your webserver.

Yes, that is correct. Using curl to launch the script via the web server.

> 1.  Modify the script so that it does actually output something, thereby
> making the error go away.


When the script starts, it prints a banner with the script name and
date/time stamp. When it completes, it is supposed to print aggregate
results, time spent. I know it's encountering this problem before it
reaches the end as not all the data gets processed. I can't tell where
it is stopping though. If I put it in debug mode, it prints out a lot
of data from the beginning of the script, and never encounters this
problem.

> 2.  Run the script directly with PHP instead of via your webserver.  E.g.:
> php -f <yourscriptname>

The way the script is designed, it depends on some $_SERVER values,
which wouldn't be set if running directly from the shell.

--- End Message ---
--- Begin Message ---
On Fri, Aug 26, 2011 at 6:48 PM, tamouse mailing lists
<tamouse.li...@gmail.com> wrote:
> On Fri, Aug 26, 2011 at 1:42 PM, Geoff Shang <ge...@quitelikely.com> wrote:
>> I put this into Google and got this:
>> http://htmlfixit.com/cgi-tutes/tutorial_Common_Web_dev_error_messages_and_what_they_mean.php#premature
>
>
> Yeah, I saw that too. I do know the mechanism that is happening. I
> just can't figure out where the problem is without inserting print
> statements.
>
>> Presumably, you are calling this cron job with some process which runs the
>> PHP script through a URL on your webserver.
>
> Yes, that is correct. Using curl to launch the script via the web server.
>
>> 1.  Modify the script so that it does actually output something, thereby
>> making the error go away.
>
>
> When the script starts, it prints a banner with the script name and
> date/time stamp. When it completes, it is supposed to print aggregate
> results, time spent. I know it's encountering this problem before it
> reaches the end as not all the data gets processed. I can't tell where
> it is stopping though. If I put it in debug mode, it prints out a lot
> of data from the beginning of the script, and never encounters this
> problem.
>
>> 2.  Run the script directly with PHP instead of via your webserver.  E.g.:
>> php -f <yourscriptname>
>
> The way the script is designed, it depends on some $_SERVER values,
> which wouldn't be set if running directly from the shell.
>

Again, I want to say that this script does NOT fail in dev, test and
stage, only production.

--- End Message ---
--- Begin Message ---
I had the same problem the other day and it was because a certain index in an 
array didn't exist, this array was constructed from the db and later i was 
trying to access this array.

So my best guess would be that if it happens only at production and db data is 
involved, i would definitly think in arrays, indexes, limits, etc.

Sent from my iPhone 5 Beta [Confidential use only]

On 26-08-2011, at 19:49, tamouse mailing lists <tamouse.li...@gmail.com> wrote:

> On Fri, Aug 26, 2011 at 6:48 PM, tamouse mailing lists
> <tamouse.li...@gmail.com> wrote:
>> On Fri, Aug 26, 2011 at 1:42 PM, Geoff Shang <ge...@quitelikely.com> wrote:
>>> I put this into Google and got this:
>>> http://htmlfixit.com/cgi-tutes/tutorial_Common_Web_dev_error_messages_and_what_they_mean.php#premature
>> 
>> 
>> Yeah, I saw that too. I do know the mechanism that is happening. I
>> just can't figure out where the problem is without inserting print
>> statements.
>> 
>>> Presumably, you are calling this cron job with some process which runs the
>>> PHP script through a URL on your webserver.
>> 
>> Yes, that is correct. Using curl to launch the script via the web server.
>> 
>>> 1.  Modify the script so that it does actually output something, thereby
>>> making the error go away.
>> 
>> 
>> When the script starts, it prints a banner with the script name and
>> date/time stamp. When it completes, it is supposed to print aggregate
>> results, time spent. I know it's encountering this problem before it
>> reaches the end as not all the data gets processed. I can't tell where
>> it is stopping though. If I put it in debug mode, it prints out a lot
>> of data from the beginning of the script, and never encounters this
>> problem.
>> 
>>> 2.  Run the script directly with PHP instead of via your webserver.  E.g.:
>>> php -f <yourscriptname>
>> 
>> The way the script is designed, it depends on some $_SERVER values,
>> which wouldn't be set if running directly from the shell.
>> 
> 
> Again, I want to say that this script does NOT fail in dev, test and
> stage, only production.
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

--- End Message ---

Reply via email to