PHP CSV

[Joydeep Chakrabarty]

Hello,

I am trying to read a CSV file from my web server. Here is my code.

<?php
$file = "http://localhost/x.csv";
$fp = fopen ($file, "r");
if (!$file) {
echo "<p>Unable to open remote file.\n";
exit;
}
while(!feof($fp)) {
$data = fgetcsv($file, 1024);
print "Data = " . $data[0] . "<BR>";
}
fclose($fp);
?>

It can access my csv file in my document root folder. But it gets into
infinite loop and does not display anything from $data array. Is there
something I am missing?
Please help.

Thanks.

[Markus Heinz]

Hello.

You do not check correctly if the file has been opened. It looks like
you have interchanged $file and $fp in the if statement. So my
assumption is the file is not opened at all and this causes the infinite
loop because feof will return false if the file pointer is not valid.

Furthermore you should consider using a local path in the fopen call if
the CSV file is on the same server anyways.

Regards

Markus

[Christoph M. Becker]

Markus Heinz wrote:

> Furthermore you should consider using a local path in the fopen call if
> the CSV file is on the same server anyways.

ACK

Furthermore I would suggest to avoid feof(), and instead check the
return value of fgetcsv():

while (($data = fgetcsv($handle, 1024)) !== FALSE) {

--
Christoph M. Becker

[Joydeep Chakrabarty]

Hello,

Sorry, that's a mistake. I changed that to $fp, but, still having the same
problem. It's going into infinite loop and taking too much time to load. I
put echo statement at every line to see whether file exists or not, whether
file opens right or not, etc.

Thanks.


For local path, it's working.

[Derek Turner]

On Thu, 18 Dec 2014 18:13:23 +0530, Joydeep Chakrabarty wrote:

> For local path, it's working.

IIRC the default setting for PHP allows only local paths: there is a
setting that allows URIs to be used but it needs to be enabled.

I could very well be mis-remembering.

[Joydeep Chakrabarty]

I changed my code to that. Now, my code is -

<?php
$file = "http://localhost/x.csv";
$fp = fopen ($file, "r");
if (!$file) {
echo "<p>Unable to open remote file.\n";
exit;
}

while (($data = fgetcsv($fp, 1024)) !== FALSE) {

print "Data = " . $data[0] . "<BR>";
}
fclose($fp);
?>

Same problem.

Thanks.

[Joydeep Chakrabarty]

You might be talking about allow_url_fopen flag. I checked that. It is on.

if (ini_get('allow_url_fopen') == '1') {
echo "use fopen() or file_get_contents()";
} else {
echo "use curl or your custom function";
}

[Derek Turner]

On Thu, 18 Dec 2014 18:33:14 +0530, Joydeep Chakrabarty wrote:

> You might be talking about allow_url_fopen flag. I checked that. It is
> on.

I was, and I was wrong: the default is "on".

[Jerry Stuckle]

What happens if you try to access http://localhost/x.csv from a browser?

Did you follow Christoph's suggestion to check the return value of
fgetcsv() instead of using feof()?


--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Markus Heinz]

Hello.

On 2014-12-18 at 13:56 Joydeep Chakrabarty wrote:
> I changed my code to that. Now, my code is -
>
> <?php
> $file = "http://localhost/x.csv";
> $fp = fopen ($file, "r");
> if (!$file) {
> echo "<p>Unable to open remote file.\n";
> exit;
> }
> while (($data = fgetcsv($fp, 1024)) !== FALSE) {
> print "Data = " . $data[0] . "<BR>";
> }
> fclose($fp);
> ?>
>
> Same problem.

This code snippet still contains the same error as the original one
regarding the if statement.

If the fopen fails it should issue a warning. If the warning is not
displayed on screen, it should be found in the server logs. For apache
this is the file "error.log".

Regards

Markus

[Christoph M. Becker]

Joydeep Chakrabarty wrote:

> Sorry, that's a mistake. I changed that to $fp, but, still having the same
> problem. It's going into infinite loop and taking too much time to load. I
> put echo statement at every line to see whether file exists or not, whether
> file opens right or not, etc.
>

> For local path, it's working.

Are you sure there is an infinite loop, or is it just that the script
hangs? The former should cause respective CPU load; the latter not.

If you're using the built-in web server of PHP, the script will hang,
because this web server is not able to handle nested requests to itself.

--
Christoph M. Becker

[Jerry Stuckle]

Whether it shows up in the server log and where the log is located is
completely dependent on the PHP configuration. There may or may not be
messages in the file, and it may or may not be known as "error.log".

> Regards
>
> Markus

[Joydeep Chakrabarty]

That's right. I changed my code to just -

$fp = fopen ($file, "r") or die("Unable to open file");

It returned "Unable to open file".
So it was wrong. What is the right way to access the file?

Thanks.

[Markus Heinz]

On 2014-12-18 at 16:26 Joydeep Chakrabarty wrote:
> Markus Heinz wrote:
>

>> On 2014-12-18 at 13:56 Joydeep Chakrabarty wrote:
>>> I changed my code to that. Now, my code is -
>>>
>>> <?php
>>> $file = "http://localhost/x.csv";
>>> $fp = fopen ($file, "r");
>>> if (!$file) {
>>> echo "<p>Unable to open remote file.\n";
>>> exit;
>>> }
>>> while (($data = fgetcsv($fp, 1024)) !== FALSE) {
>>> print "Data = " . $data[0] . "<BR>";
>>> }
>>> fclose($fp);
>>> ?>
>>>
>>> Same problem.
>>
>> This code snippet still contains the same error as the original one
>> regarding the if statement.
>>
>> If the fopen fails it should issue a warning. If the warning is not
>> displayed on screen, it should be found in the server logs. For apache
>> this is the file "error.log".
>>

> That's right. I changed my code to just -
>
> $fp = fopen ($file, "r") or die("Unable to open file");
>
> It returned "Unable to open file".
> So it was wrong. What is the right way to access the file?

Do you have PHP warnings enabled in your configuration? If so, did you
check the server logs for a message about the failed fopen? There should
be a hint about the cause.

Is it required that the CSV files can be fetched from different servers
or will they always be on the same server your script runs on?

If the CVS files are always on the same server you should be able to
open them with a local path:

$file = $_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . 'x.csv';
$fp = fopen($file, 'r') or die("Unable to open file");

Regards

Markus

[Christoph M. Becker]

Markus Heinz wrote:

> On 2014-12-18 at 16:26 Joydeep Chakrabarty wrote:
>
>> Markus Heinz wrote:
>>
>>> If the fopen fails it should issue a warning. If the warning is not
>>> displayed on screen, it should be found in the server logs. For apache
>>> this is the file "error.log".
>>>
>> That's right. I changed my code to just -
>>
>> $fp = fopen ($file, "r") or die("Unable to open file");
>>
>> It returned "Unable to open file".
>> So it was wrong. What is the right way to access the file?
>
> Do you have PHP warnings enabled in your configuration? If so, did you
> check the server logs for a message about the failed fopen? There should
> be a hint about the cause.

From php.ini (PHP 5.4):

; display_errors
; Development Value: On

; display_startup_errors
; Development Value: On

; error_reporting
; Development Value: E_ALL


I suggest to use the suggested development values in a development
environment. Then there is no need to consult the error log.

--
Christoph M. Becker

[Joydeep Chakrabarty]

My CSV file is in the same server. I changed my code according to your
suggestion. But it gives me "Unable to open file".

<?php

$file = $_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . 'x.csv';

echo $file . "<br />\n";

$fp = fopen ($file, "r") or die("Unable to open file");

fclose($fp);
?>


Thanks.

[Markus Heinz]

> My CSV file is in the same server. I changed my code according to your
> suggestion. But it gives me "Unable to open file".
>
> <?php
> $file = $_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . 'x.csv';
> echo $file . "<br />\n";
> $fp = fopen ($file, "r") or die("Unable to open file");
> fclose($fp);
> ?>

There are at least two possibilities. The most obvious are:

1. The path to the file is wrong. Is it really located in the top folder
of the document root of your webserver as you wrote in the first code
snippet?
2. The web server process does not have read permission on the file.

Regards

Markus

[Joydeep Chakrabarty]

You are right. There was no read permission. I changed it and it's
working perfectly. Thank you very much.

Thanks.

[Olaf Schmitt]

Am 18.12.2014 um 13:56 schrieb Joydeep Chakrabarty:
> Christoph M. Becker wrote:
>
>> Markus Heinz wrote:
>>
>>> Furthermore you should consider using a local path in the fopen call if
>>> the CSV file is on the same server anyways.
>>
>> ACK
>>
>> Furthermore I would suggest to avoid feof(), and instead check the
>> return value of fgetcsv():
>>
>> while (($data = fgetcsv($handle, 1024)) !== FALSE) {
>>
>
> I changed my code to that. Now, my code is -
>
> <?php
> $file = "http://localhost/x.csv";
> $fp = fopen ($file, "r");

^^^^^^

> if (!$file) {
^^^^^^

> Same problem.
Same bug.

[Denis McMahon]

On Thu, 18 Dec 2014 18:26:25 +0530, Joydeep Chakrabarty wrote:

> Christoph M. Becker wrote:
>
>> Markus Heinz wrote:
>>
>>> Furthermore you should consider using a local path in the fopen call
>>> if the CSV file is on the same server anyways.
>>
>> ACK
>>
>> Furthermore I would suggest to avoid feof(), and instead check the
>> return value of fgetcsv():
>>
>> while (($data = fgetcsv($handle, 1024)) !== FALSE) {
>>
>>
> I changed my code to that. Now, my code is -
>
> <?php
> $file = "http://localhost/x.csv";
> $fp = fopen ($file, "r");
> if (!$file) {

This line should be checking $fp, not $file.

$file is a text string, it will always be true, even if the fopen fails.

What you should be checking is the file handle resource returned by fopen,
which is $fp.

What happens when you open a browser on this machine and request the uri
http://localhost/x.csv

Failing that, if you have no access to a browser on the machine, then in
a command shell try[1]:

$ wget http://localhost/x.csv

or even:

$ nc localhost 80
get x.csv http/1.0

(note - you need to press return twice after 'get x.csv http/1.0')

or:

$ telnet localhost 80
get x.csv http/1.0

(again, 2 returns after 'get x.csv http/1.0')

These are basic checks to verify that your server is delivering the
requested file. Once we have confirmed that, then is the time to worry
about why php isn't reading it.

[1] These are unix / linux type commands, you might not have them
available if you use other operating systems, and you might need to
install them first although most linuxes include at least telnet. telnet
and wget should be freely available for most operating systems. use your
favourite search engine to find them from a reputable source.
--
Denis McMahon, denismf...@gmail.com

[Jerry Stuckle]

You should never use die() (or exit() on a production server. It
terminates processing of the script immediately, which produces invalid
(x)html. Plus it looks like crap to the user.

Rather, use an "if" statement to branch around the code which uses the
unavailable resource and complete other processing.

[Christoph M. Becker]

Tim Streater wrote:

> In article <m702rq$1a9$1...@dont-email.me>, Jerry Stuckle

> <jstu...@attglobal.net> wrote:
>
>> On 12/18/2014 11:22 AM, Joydeep Chakrabarty wrote:
>>
>>> <?php
>>> $file = $_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . 'x.csv';
>>> echo $file . "<br />\n";
>>> $fp = fopen ($file, "r") or die("Unable to open file");
>>> fclose($fp);
>>> ?>
>>

>> You should never use die() (or exit() on a production server. It
>> terminates processing of the script immediately, which produces invalid
>> (x)html. Plus it looks like crap to the user.

While I absolutely agree that it is a very bad idea to terminate the
script in the middle of the output, prohibiting die or exit in a
production environment is too hard and fast a rule, IMO. It's like
forbidding return, unless as the last statement of a function.

> I dunno why the OP doesn't read the documentation. What I do is:

>
> $fp = fopen ($file, "r")

> if ($fp===false)
> {
> // Perform error processing here, log the error in my log file
> // and notify the remote end appropriately
> exit ();
> }

What I would do is something like:

read_the_file();
generate_output();

IOW: I would separate the presentation code from the domain code.

--
Christoph M. Becker

[Jerry Stuckle]

On 12/19/2014 8:05 AM, Christoph M. Becker wrote:
> Tim Streater wrote:
>
>> In article <m702rq$1a9$1...@dont-email.me>, Jerry Stuckle
>> <jstu...@attglobal.net> wrote:
>>
>>> On 12/18/2014 11:22 AM, Joydeep Chakrabarty wrote:
>>>
>>>> <?php
>>>> $file = $_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . 'x.csv';
>>>> echo $file . "<br />\n";
>>>> $fp = fopen ($file, "r") or die("Unable to open file");
>>>> fclose($fp);
>>>> ?>
>>>
>>> You should never use die() (or exit() on a production server. It
>>> terminates processing of the script immediately, which produces invalid
>>> (x)html. Plus it looks like crap to the user.
>
> While I absolutely agree that it is a very bad idea to terminate the
> script in the middle of the output, prohibiting die or exit in a
> production environment is too hard and fast a rule, IMO. It's like
> forbidding return, unless as the last statement of a function.
>

return does not create invalid output. die() and exit() do.

I have *never* found a need for either one in a properly constructed
script.

>> I dunno why the OP doesn't read the documentation. What I do is:
>>
>> $fp = fopen ($file, "r")
>> if ($fp===false)
>> {
>> // Perform error processing here, log the error in my log file
>> // and notify the remote end appropriately
>> exit ();
>> }
>
> What I would do is something like:
>
> read_the_file();
> generate_output();
>
> IOW: I would separate the presentation code from the domain code.
>

I don't think it's necessarily a good idea to do this. If the functions
are only called one from one place, it upsets the flow of the script,
making the reader go back and forth to follow processing. It also means
you have to read the entire script in before generating any output,
instead of completely processing the input line by line.

I prefer something like:

$fp = fopen ($file, "r")

if ($fp) {
// Read the file and process it
}
else {

// Perform error processing here, log the error in my log file
// and notify the remote end appropriately
}

[Matthew Carter]

Exceptions work pretty well (instead of many if/else blocks). Then you
can handle your output at the end if the process fails (and line by line
if it doesn't).

--
Matthew Carter (m...@ahungry.com)
http://ahungry.com

[Jerry Stuckle]

True, exceptions help a lot. But unfortunately, this also ends up in a
group of nested blocks - just try/catch instead of if/else.

IMHO the biggest advantage to exceptions is they can cross function
boundaries (i.e throw an exception in a function then handle it in the
called function) - which can be a great help.

Don't get me wrong - I love exceptions. But, unfortunate, like any
other coding convention, it's not the answer to life, the universe and
everything :)

[M. Strobel]

I think so as well. In another language (ocaml) they use exceptions for end of file
and other "regular" conditions, so one gets to understand that it is just another
structure tool. Provided they are cheap (in Java they are not so cheap).

In PHP, for example when using PDO, it saves you the need to check every return code.
But you should take care to capture the exception only at the level where you can
decide if/how to continue.

/Str.

[Erwin Moller]

On 12/19/2014 4:59 PM, Jerry Stuckle wrote:

<snip>

>
> return does not create invalid output. die() and exit() do.
>
> I have *never* found a need for either one in a properly constructed
> script.
>

I use exit() after a header location combi.

if (whatever){
dostuff();
header("location: ....");
exit;
}

It is an easy way to redirect, and terminate the script, and not having
a (possibly huge) else-part.

Do you (Jerry) think that that approach isn't properly?
If so, why?


Regards,
Erwin Moller

--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

[Jerry Stuckle]

On 2/4/2015 7:19 AM, Erwin Moller wrote:
> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
>
> <snip>
>>
>> return does not create invalid output. die() and exit() do.
>>
>> I have *never* found a need for either one in a properly constructed
>> script.
>>
>
> I use exit() after a header location combi.
>
> if (whatever){
> dostuff();
> header("location: ....");
> exit;
> }
>
> It is an easy way to redirect, and terminate the script, and not having
> a (possibly huge) else-part.
>
> Do you (Jerry) think that that approach isn't properly?
> If so, why?
>
>
> Regards,
> Erwin Moller
>

With a properly constructed script, you don't need to call exit() after
a header() call, either.

[Jerry Stuckle]

On 2/4/2015 8:29 AM, Tim Streater wrote:
> In article <mat59b$qn4$1...@dont-email.me>, Jerry Stuckle

> <jstu...@attglobal.net> wrote:
>
>> On 2/4/2015 7:19 AM, Erwin Moller wrote:
>>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
>
>>>> return does not create invalid output. die() and exit() do.
>>>>
>>>> I have *never* found a need for either one in a properly constructed
>>>> script.
>
>>> I use exit() after a header location combi.
>>>
>>> if (whatever){
>>> dostuff();
>>> header("location: ....");
>>> exit;
>>> }
>>>
>>> It is an easy way to redirect, and terminate the script, and not having
>>> a (possibly huge) else-part.
>>>
>>> Do you (Jerry) think that that approach isn't properly?
>>> If so, why?
>

>> With a properly constructed script, you don't need to call exit() after
>> a header() call, either.
>

> I use exit when processing is complete. Sometimes that happens inside
> an "if" or other construct.
>
> I certainly don't intend, ever, to use convoluted if/then/else just so
> that processing always arrives at the last line of a script.
>

Which terminates processing immediately - and anything after that point
(such as </BODY> and </HTML> tags is not sent to the browser. This
causes an invalid page to be generated.

Do your clients know you're generating invalid HTML for them?

[Erwin Moller]

In my above example, the script did something useful in doStuff();
Then, redirects to another page with the header("location: ....").

I never intended to give the idea my example was outputting HTML to a
browser (but should have said so to avoid confusion).

I often use PHP to processing some posting/do some task, and when
finished, set header/location to another page. (That will also avoid
the dreaded back-button/formpost confirmation that confuses most
non-webprogrammers = 99.9% of the world).

So using exit() seems completely valid to me.

For clarity's sake: I dislike half-finished HTML too, just like you, and
when the script produces output, it *should* finish the document in a
valid way. No discussion there.

You just triggered me by your statement that you never use exit(), when
you program properly.
I use exit for the very reason Tim Steater gave: to avoid too much code
into if-then-else constructs, for the sake of finishing at some point at
the end.
IMHO it makes the script less readable.

Regards,
Erwin Moller

PS: If in your opinion only MVC is proper programming, than I can see
why you never encounter exit() anymore.

[Jerry Stuckle]

On 2/4/2015 10:26 AM, Tim Streater wrote:
> In article <mat90n$af9$1...@dont-email.me>, Jerry Stuckle

> My scripts don't generate HTML. They generate data, which is
> interpreted client-side and used to update what is presented to the
> user.
>

So you use some convoluted method of sending data to a client and having
something run on the client to interpret and display it?

Rather than simply generating HTML on the server and sending it to the
client, like the rest of the world does?

[Jerry Stuckle]

I never do use exit(). There is no need for it, even in your example.
Proper code structure eliminates the problem. Structured programming
does not make code less readable, if it's done properly. And it does
make the code more maintainable. You don't have to, for instance, try
to analyze a bunch of code to determine why your change did not take
effect - because you had already exited the code earlier.

I've just seen too many problems in other languages such as C/C++ caused
by people not wanting to structure their code properly with if-then-else
statements - and the problems it can cause.

[Paul Herber]

That is one of the worst misinterpretations of what might be happening that I've seen you
do. The data being sent could be all sorts of things. The script could be updating a
database. Nothing says that any HTML has to be generated.



--
Regards, Paul Herber, Sandrila Ltd.
http://www.sandrila.co.uk/

[Jerry Stuckle]

Paul, we are talking web pages here - not CLI scripts.

[Erwin Moller]

There is no "problem" to eliminate.
We differ in opinion here: When exit() is used properly (=in a logical
place), it is all very clear what is going on.

Structured programming
> does not make code less readable, if it's done properly. And it does
> make the code more maintainable. You don't have to, for instance, try
> to analyze a bunch of code to determine why your change did not take
> effect - because you had already exited the code earlier.

That totally depends on the place where the exit() is used.
I often have a bunch of these to process different kinds of situations:

if (whatever){
dostuff();
header("location: ....");
exit;
}

if (whatever2){
dostuff2();

header("location: ....");
exit;
}

If you would read through that code, you would surely find the exits
right away, I am sure.

But, of course, when the exit() is hidden somewhere horribly deep away,
in a totally idiotic place, then yes, that would be a problem.

In my opinion that is matter of programming hygiene.

>
> I've just seen too many problems in other languages such as C/C++ caused
> by people not wanting to structure their code properly with if-then-else
> statements - and the problems it can cause.
>

Well, yes.
C/C++ is really a different beast.
I use PHP for a reason: ease of programming in a forgiving environment
(type juggling, no memory allocation, strong array structure/functions,
etc).

It is, of course, possible to screw up royally in any language.

I think I heard that line first from you when I entered usenet, a
hundred years ago. :-)

Regards,
Erwin Moller

[Jerry Stuckle]

On 2/4/2015 12:08 PM, Tim Streater wrote:
> In article <math1o$d7a$1...@dont-email.me>, Jerry Stuckle
> <jstu...@attglobal.net> wrote:

>
>> On 4/2/2015 11:11, Paul Herber wrote:
>
>>> That is one of the worst misinterpretations of what might be
>>> happening that
>>> I've seen you do. The data being sent could be all sorts of things. The
>>> script could be updating a database. Nothing says that any HTML has
>>> to be generated.
>
>> Paul, we are talking web pages here - not CLI scripts.
>

> I'm not. I'm talking about using exit in the middle of a script.
>

This whole conversation - until you - has been about web pages.

[Jerry Stuckle]

On 2/4/2015 12:05 PM, Tim Streater wrote:
> In article <mateh0$1np$1...@dont-email.me>, Jerry Stuckle

> <jstu...@attglobal.net> wrote:
>
>> On 2/4/2015 10:26 AM, Tim Streater wrote:
>>> In article <mat90n$af9$1...@dont-email.me>, Jerry Stuckle
>>> <jstu...@attglobal.net> wrote:
>>>
>>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>>> In article <mat59b$qn4$1...@dont-email.me>, Jerry Stuckle
>>>>> <jstu...@attglobal.net> wrote:
>
>>>> Do your clients know you're generating invalid HTML for them?
>>>
>>> My scripts don't generate HTML. They generate data, which is
>>> interpreted client-side and used to update what is presented to the
>>> user.
>>
>> So you use some convoluted method of sending data to a client and having
>> something run on the client to interpret and display it?
>

> Using ajax is hardly "convoluted". And the something is a browser. You
> may have heard of them.
>

Yup, and overuse of ajax is very convoluted.

Besides - how do you get the ajax to the browser? You said you didn't
generate any html.

>> Rather than simply generating HTML on the server and sending it to the
>> client, like the rest of the world does?
>

> I'm not generating web pages, I'm running an application. You know,
> like where you double-click on an icon and an app starts and eventually
> a window appears and the user does some stuff in it.
>
> The PHP scripts (which also run on the user's machine) are a useful
> backend where I can do stuff that browsers are not allowed to.
>

This whole thread has been about web pages - until you popped in.

[Jerry Stuckle]

You obviously haven't worked on big projects with 20-50 programmers
working for 1-3 years. Or had to go back and make a change to a program
with 10K+ LOC that isn't well structured. It can be a huge problem.

> Structured programming
>> does not make code less readable, if it's done properly. And it does
>> make the code more maintainable. You don't have to, for instance, try
>> to analyze a bunch of code to determine why your change did not take
>> effect - because you had already exited the code earlier.
>
> That totally depends on the place where the exit() is used.
> I often have a bunch of these to process different kinds of situations:
>
> if (whatever){
> dostuff();
> header("location: ....");
> exit;
> }
>
> if (whatever2){
> dostuff2();
> header("location: ....");
> exit;
> }
>
> If you would read through that code, you would surely find the exits
> right away, I am sure.
>
> But, of course, when the exit() is hidden somewhere horribly deep away,
> in a totally idiotic place, then yes, that would be a problem.
>
> In my opinion that is matter of programming hygiene.
>

Yup, and along the same lines:

if (whatever) {
dostuff();
header("location: ....");

} elseif (whatever2) {

dostuff();
header("location: ....");
}

Clear, concise, and no exit() required

>
>>
>> I've just seen too many problems in other languages such as C/C++ caused
>> by people not wanting to structure their code properly with if-then-else
>> statements - and the problems it can cause.
>>
>
> Well, yes.
> C/C++ is really a different beast.
> I use PHP for a reason: ease of programming in a forgiving environment
> (type juggling, no memory allocation, strong array structure/functions,
> etc).
>

It's a different beast - but it's still the same structured programming
concepts. PHP obviously took much of its syntax from C. And structured
programming has nothing to do with type juggling, memory allocation, etc.

> It is, of course, possible to screw up royally in any language.
>
> I think I heard that line first from you when I entered usenet, a
> hundred years ago. :-)
>
> Regards,
> Erwin Moller
>

Could be. I've seen a lot of screw-ups in my decades of programming.
And not all were from newbies. Some were from people who should know
better.

[Jerry Stuckle]

On 2/4/2015 1:14 PM, Tim Streater wrote:
> In article <matm2e$42c$2...@dont-email.me>, Jerry Stuckle

> <jstu...@attglobal.net> wrote:
>
>> On 2/4/2015 12:05 PM, Tim Streater wrote:
>>> In article <mateh0$1np$1...@dont-email.me>, Jerry Stuckle
>>> <jstu...@attglobal.net> wrote:
>>>
>>>> On 2/4/2015 10:26 AM, Tim Streater wrote:
>>>>> In article <mat90n$af9$1...@dont-email.me>, Jerry Stuckle
>>>>> <jstu...@attglobal.net> wrote:
>>>>>
>>>>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>>>>> In article <mat59b$qn4$1...@dont-email.me>, Jerry Stuckle
>>>>>>> <jstu...@attglobal.net> wrote:
>>>
>>>>>> Do your clients know you're generating invalid HTML for them?
>>>>>
>>>>> My scripts don't generate HTML. They generate data, which is
>>>>> interpreted client-side and used to update what is presented to the
>>>>> user.
>>>>
>>>> So you use some convoluted method of sending data to a client and
>>>> having
>>>> something run on the client to interpret and display it?
>>>
>>> Using ajax is hardly "convoluted". And the something is a browser. You
>>> may have heard of them.
>>>
>>
>> Yup, and overuse of ajax is very convoluted.
>>
>> Besides - how do you get the ajax to the browser? You said you didn't
>> generate any html.
>

> The basic page is loaded when the app starts. It's an email client. So
> it does what all email clients do - presents an interface in various
> ways, downloads mail, filters it, checks for spam, saves into
> databases. Presentation is done by the browser, all the rest by various
> PHP scripts.
>

So you do generate HTML then.

[Matthew Carter]

Jerry Stuckle <jstu...@attglobal.net> writes:

> On 2/4/2015 1:14 PM, Tim Streater wrote:
>> In article <matm2e$42c$2...@dont-email.me>, Jerry Stuckle
>> <jstu...@attglobal.net> wrote:
>>

>> <snip>

>>
>> The basic page is loaded when the app starts. It's an email client. So
>> it does what all email clients do - presents an interface in various
>> ways, downloads mail, filters it, checks for spam, saves into
>> databases. Presentation is done by the browser, all the rest by various
>> PHP scripts.
>>
>
> So you do generate HTML then.

AJAX responses aren't typically HTML - why would you send HTML instead
of JSON?

Or are you inferring that JSON is HTML?

I *very* rarely see HTML as a result of an AJAX request, normally I see
JSON or plain text, which is then parsed via javascript and HTML
elements updated as necessary via DOM updates on the client side.

The text/html content type header is not even necessary in these cases.

I think more and more websites/SAAS are using and will be using AJAX
going forward - HTML is just a small part of a bigger picture.

[Christoph M. Becker]

Matthew Carter wrote:

> I *very* rarely see HTML as a result of an AJAX request, normally I see
> JSON or plain text, which is then parsed via javascript and HTML
> elements updated as necessary via DOM updates on the client side.

Ajax stands for "Asynchronous JavaScript And XML". So neither HTML,
JSON, nor plain text responses have anything to do with it -- otherwise,
where would be the XML? ;)

--
Christoph M. Becker

[Jerry Stuckle]

How do you get the AJAX to the browser if you don't generate HTML?

[Jerry Stuckle]

Yes, but the javascript needs to be sent to the browser in an HTML page.

[Thomas 'PointedEars' Lahn]

Erwin Moller wrote:

> On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
>> Do your clients know you're generating invalid HTML for them?
>
> In my above example, the script did something useful in doStuff();
> Then, redirects to another page with the header("location: ....").

header('30… … HTTP/1.…');
header('Location: …');

is safer.

> I never intended to give the idea my example was outputting HTML to a
> browser (but should have said so to avoid confusion).
>
> I often use PHP to processing some posting/do some task, and when
> finished, set header/location to another page. (That will also avoid
> the dreaded back-button/formpost confirmation that confuses most
> non-webprogrammers = 99.9% of the world).
>
> So using exit() seems completely valid to me.

Of course it is. “Only a Sith deals in absolutes.”

> […]

> PS: If in your opinion only MVC is proper programming, than I can see
> why you never encounter exit() anymore.

Even with MVC there are valid reasons to use die() and exit().

--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[Christoph M. Becker]

Thomas 'PointedEars' Lahn wrote:

> Erwin Moller wrote:
>
>> On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
>>> Do your clients know you're generating invalid HTML for them?
>>
>> In my above example, the script did something useful in doStuff();
>> Then, redirects to another page with the header("location: ....").
>
> header('30… … HTTP/1.…');
> header('Location: …');
>
> is safer.

Wouldn't it be equally safe to set the $http_response_code argument?

header('Location: …', true, 30…);

>> PS: If in your opinion only MVC is proper programming, than I can see
>> why you never encounter exit() anymore.
>
> Even with MVC there are valid reasons to use die() and exit().

ACK.

--
Christoph M. Becker

[Jerry Stuckle]

On 2/6/2015 5:26 PM, Thomas 'PointedEars' Lahn wrote:
> Erwin Moller wrote:
>
>> On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
>>> Do your clients know you're generating invalid HTML for them?
>>
>> In my above example, the script did something useful in doStuff();
>> Then, redirects to another page with the header("location: ....").
>
> header('30… … HTTP/1.…');
> header('Location: …');
>
> is safer.
>

Only if it is a temporary or permanent redirect - that is, the user
should go to the new page INSTEAD of the current page.

In the case of the current page performing some processing then
redirecting to the new page, this would be incorrect.

[Jerry Stuckle]

There are NEVER valid reasons to knowingly send invalid HTML to the
user. Only a hacker or an idiot would do so.

Of course, we know some of the people here are both.

[Christoph M. Becker]

Jerry Stuckle wrote:

> On 2/6/2015 5:26 PM, Thomas 'PointedEars' Lahn wrote:
>> Erwin Moller wrote:
>>
>>> On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
>>>> Do your clients know you're generating invalid HTML for them?
>>>
>>> In my above example, the script did something useful in doStuff();
>>> Then, redirects to another page with the header("location: ....").
>>
>> header('30… … HTTP/1.…');
>> header('Location: …');
>>
>> is safer.
>>
>
> Only if it is a temporary or permanent redirect - that is, the user
> should go to the new page INSTEAD of the current page.
>
> In the case of the current page performing some processing then
> redirecting to the new page, this would be incorrect.

Ever heard of "303 See other"?

--
Christoph M. Becker

[Thomas 'PointedEars' Lahn]

Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Erwin Moller wrote:
>>> On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
>>>> Do your clients know you're generating invalid HTML for them?
>>> In my above example, the script did something useful in doStuff();
>>> Then, redirects to another page with the header("location: ....").
>>
>> header('30… … HTTP/1.…');

Ouch. I confused the order of response parameters. Should be

header('HTTP/1.… 30… …');

>> header('Location: …');
>>
>> is safer.
>
> Wouldn't it be equally safe to set the $http_response_code argument?
>
> header('Location: …', true, 30…);

Supported since PHP 4.3.0. Good catch. <http://php.net/header>

However, by contrast, using giving HTTP response status line allows you to
specify, and negotiate, the protocol version.

[Thomas 'PointedEars' Lahn]

ACK. Providing the proper response status code is important for users; it
can be even more important for search engines. Because if you are on the
Web, you want to be found:

<https://support.google.com/webmasters/answer/40132?hl=en>

<http://searchenginewatch.com/sew/how-to/2340728/matt-cutts-on-how-google-handles-404-410-status-codes> pp.

[Thomas 'PointedEars' Lahn]

Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Erwin Moller wrote:
>>> On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
>>>> Do your clients know you're generating invalid HTML for them?
>>> In my above example, the script did something useful in doStuff();
>>> Then, redirects to another page with the header("location: ....").
>>
>> header('30… … HTTP/1.…');

Ouch. I confused the order of response parameters. Should be

header('HTTP/1.… 30… …');

>> header('Location: …');
>>
>> is safer.
>
> Wouldn't it be equally safe to set the $http_response_code argument?
>
> header('Location: …', true, 30…);

Supported since PHP 4.3.0. Good catch. <http://php.net/header>

However, by contrast, giving the HTTP response status line allows you to

specify, and negotiate, the protocol version.

[Christoph M. Becker]

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
>
>> Jerry Stuckle wrote:
>>
>>> In the case of the current page performing some processing then
>>> redirecting to the new page, this would be incorrect.
>>
>> Ever heard of "303 See other"?
>
> ACK. Providing the proper response status code is important for users; it
> can be even more important for search engines. Because if you are on the
> Web, you want to be found:

ACK. However, I was responding in particular to Jerry's claim, that
redirection after performing some processing would be incorrect.
According to RFC 7321[1]:

| [...] It [the 303 status code] is primarily used to allow the output
| of a POST action to redirect the user agent to a selected resource,
| [...]

[1] <http://tools.ietf.org/html/rfc7231#section-6.4.4>

--
Christoph M. Becker

[Christoph M. Becker]

Jerry Stuckle wrote:

> On 2/6/2015 7:38 PM, Christoph M. Becker wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>
>>> Even with MVC there are valid reasons to use die() and exit().
>>
>> ACK.
>>
>
> There are NEVER valid reasons to knowingly send invalid HTML to the
> user. Only a hacker or an idiot would do so.

Nobody was suggesting to send invalid HTML.

--
Christoph M. Becker

[Jerry Stuckle]

Yes, I have. But you obviously don't understand what it to be used for.
It's purpose is to allow redirection to a specific resource, not
process a request and redirect. See RFC7231.

[Jerry Stuckle]

That is correct - to a "SELECTED RESOURCE". That is one that is not
identified in the POST or GET request. It is used when the request
itself does not provide enough information to return the resource, or
the original target does not have access to the resource.

Read the entire paragraph - not just one statement. Then UNDERSTAND it
- if you're capable of such (which you've shown in the past you aren't).

[Christoph M. Becker]

Jerry Stuckle wrote:

> On 2/6/2015 10:33 PM, Christoph M. Becker wrote:
>
>> Ever heard of "303 See other"?
>
> Yes, I have. But you obviously don't understand what it to be used for.
> It's purpose is to allow redirection to a specific resource, not
> process a request and redirect. See RFC7231.

*facepalm*

--
Christoph M. Becker

[Christoph M. Becker]

Jerry Stuckle wrote:

> On 2/7/2015 8:45 AM, Christoph M. Becker wrote:
>>
>> ACK. However, I was responding in particular to Jerry's claim, that
>> redirection after performing some processing would be incorrect.
>> According to RFC 7321[1]:
>>
>> | [...] It [the 303 status code] is primarily used to allow the output
>> | of a POST action to redirect the user agent to a selected resource,
>> | [...]
>>
>> [1] <http://tools.ietf.org/html/rfc7231#section-6.4.4>
>
> That is correct - to a "SELECTED RESOURCE". That is one that is not
> identified in the POST or GET request. It is used when the request
> itself does not provide enough information to return the resource, or
> the original target does not have access to the resource.

One of the most common uses of "303 See Other" is the PRG pattern, which
has nothing to do with what you're making up here.

> Read the entire paragraph - not just one statement. Then UNDERSTAND it
> - if you're capable of such (which you've shown in the past you aren't).

EOD.

--
Christoph M. Becker

[Jerry Stuckle]

Once again you show you have no understanding of basic programming
principles. But that's nothing new - you do it with virtually every
post you make.

Your clients must be really embarrassed to have to hire you.