Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14752 > unrolled thread

PHP CSV

Back to article view | Back to comp.lang.php

Contents

  PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 17:09 +0530
    Re: PHP CSV Markus Heinz <markus.heinz@uni-dortmund.de> - 2014-12-18 13:11 +0100
      Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-18 13:27 +0100
        Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 18:26 +0530
          Re: PHP CSV Markus Heinz <markus.heinz@uni-dortmund.de> - 2014-12-18 14:43 +0100
            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-18 09:24 -0500
            Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 20:56 +0530
              Re: PHP CSV Markus Heinz <markus.heinz@uni-dortmund.de> - 2014-12-18 16:57 +0100
                Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-18 17:04 +0100
                Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 21:52 +0530
                  Re: PHP CSV Markus Heinz <markus.heinz@uni-dortmund.de> - 2014-12-18 17:38 +0100
                    Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 16:49 +0000
                  Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-18 21:34 -0500
                    Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2014-12-19 09:43 +0000
                      Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-19 14:05 +0100
                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-19 10:59 -0500
                          Re: PHP CSV Matthew Carter <m@ahungry.com> - 2014-12-19 14:21 -0500
                            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-19 18:17 -0500
                            Re: PHP CSV "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2014-12-20 00:35 +0100
                          Re: PHP CSV Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-02-04 13:19 +0100
                            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 08:03 -0500
                              Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 13:29 +0000
                                Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 09:06 -0500
                                  Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 15:26 +0000
                                    Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 10:40 -0500
                                      Re: PHP CSV Paul Herber <paul@pherber.com> - 2015-02-04 16:11 +0000
                                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 11:23 -0500
                                          Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 17:08 +0000
                                            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 12:48 -0500
                                      Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 17:05 +0000
                                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 12:49 -0500
                                          Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 18:14 +0000
                                            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 13:37 -0500
                                              Re: PHP CSV Matthew Carter <m@ahungry.com> - 2015-02-04 15:23 -0500
                                                Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-04 21:54 +0100
                                                  Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 16:32 -0500
                                                Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 16:31 -0500
                                  Re: PHP CSV Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-02-04 16:39 +0100
                                    Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 10:57 -0500
                                      Re: PHP CSV Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-02-04 18:07 +0100
                                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 12:55 -0500
                                    Re: PHP CSV Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-06 23:26 +0100
                                      Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 01:38 +0100
                                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-06 19:44 -0500
                                          Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 14:49 +0100
                                        Re: PHP CSV Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-07 14:28 +0100
                                      Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-06 19:42 -0500
                                        Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 04:33 +0100
                                          Re: PHP CSV Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-07 14:26 +0100
                                            Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 14:45 +0100
                                              Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-07 08:54 -0500
                                                Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 16:54 +0100
                                                  Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-07 11:00 -0500
                                          Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-07 08:51 -0500
                                            Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 14:55 +0100
          Re: PHP CSV Olaf Schmitt <thesys@gmx.de> - 2014-12-19 01:16 +0100
          Re: PHP CSV Denis McMahon <denismfmcmahon@gmail.com> - 2014-12-19 02:14 +0000
      Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 18:13 +0530
        Re: PHP CSV Derek Turner <frderek@cesmail.net> - 2014-12-18 12:55 +0000
          Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 18:33 +0530
            Re: PHP CSV Derek Turner <frderek@cesmail.net> - 2014-12-18 13:10 +0000
        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-18 08:17 -0500
        Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-18 15:16 +0100

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#14870

On 2/4/2015 12:07 PM, Erwin Moller wrote:
> On 2/4/2015 4:57 PM, Jerry Stuckle wrote:
>> On 2/4/2015 10:39 AM, Erwin Moller wrote:
>>> On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
>>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>>>> <jstucklex@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?
>>>>
>>>
>>> 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.
>>>
>>
>> I never do use exit().  There is no need for it, even in your example.
>> Proper code structure eliminates the problem.
> 
> 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.
>

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.

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

[toc] | [prev] | [next] | [standalone]

#14877

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.

[toc] | [prev] | [next] | [standalone]

#14878

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

[toc] | [prev] | [next] | [standalone]

#14880

On 2/6/2015 7:38 PM, 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.…');
>>   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.
> 

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.

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

[toc] | [prev] | [next] | [standalone]

#14886

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

[toc] | [prev] | [next] | [standalone]

#14884

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.

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

[toc] | [prev] | [next] | [standalone]

#14879

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.

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

[toc] | [prev] | [next] | [standalone]

#14881

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

[toc] | [prev] | [next] | [standalone]

#14883

Christoph M. Becker wrote:

> Jerry Stuckle wrote: 
>> On 2/6/2015 5:26 PM, Thomas 'PointedEars' Lahn wrote:
>>> Erwin Moller wrote:
>>>> 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"?

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.

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

[toc] | [prev] | [next] | [standalone]

#14885

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

[toc] | [prev] | [next] | [standalone]

#14888

On 2/7/2015 8:45 AM, Christoph M. Becker wrote:
> 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>
> 

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).


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

[toc] | [prev] | [next] | [standalone]

#14890

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

[toc] | [prev] | [next] | [standalone]

#14891

On 2/7/2015 10:54 AM, Christoph M. Becker wrote:
> 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.
> 

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.


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

[toc] | [prev] | [next] | [standalone]

#14887

On 2/6/2015 10:33 PM, Christoph M. Becker wrote:
> 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"?
> 

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.


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

[toc] | [prev] | [next] | [standalone]

#14889

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

[toc] | [prev] | [next] | [standalone]

#14770

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.

[toc] | [prev] | [next] | [standalone]

#14771

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, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#14755

Markus Heinz wrote:

> Hello.
> 
> On 2014-12-18 at 12:39 Joydeep Chakrabarty wrote:
>> 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.
> 
> 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
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.

[toc] | [prev] | [next] | [standalone]

#14756

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.

[toc] | [prev] | [next] | [standalone]

#14758

Derek Turner wrote:

> 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.

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";
}

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.php

csiph-web