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

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

calling a value into another php script...

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

Contents

  calling a value into another php script... nag <visitnag@gmail.com> - 2013-08-28 18:35 -0700
    Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-28 22:56 -0400
      Re: calling a value into another php script... nag <visitnag@gmail.com> - 2013-08-29 06:06 -0700
        Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-29 09:31 -0400
        Re: calling a value into another php script... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-29 17:35 +0200
    Re: calling a value into another php script... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-29 11:40 +0200
    Re: calling a value into another php script... Twayne <nobody@spamcop.net> - 2013-08-29 20:18 -0400
      Re: calling a value into another php script... Christoph Michael Becker <cmbecker69@arcor.de> - 2013-08-30 02:57 +0200
        Re: calling a value into another php script... The Natural Philosopher <tnp@invalid.invalid> - 2013-08-30 02:54 +0100
          Re: calling a value into another php script... Twayne <nobody@spamcop.net> - 2013-08-30 17:15 -0400
        Re: calling a value into another php script... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-30 11:57 +0200
          Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-30 08:49 -0400
            Re: calling a value into another php script... Denis McMahon <denismfmcmahon@gmail.com> - 2013-08-30 14:30 +0000
              Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-30 11:42 -0400
                Re: calling a value into another php script... Christoph Michael Becker <cmbecker69@arcor.de> - 2013-08-31 00:19 +0200
                  Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-30 20:33 -0400
                    Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-30 20:57 -0400
                      Re: calling a value into another php script... Christoph Michael Becker <cmbecker69@arcor.de> - 2013-09-01 20:23 +0200
                        Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-01 15:09 -0400
                  Re: calling a value into another php script... Denis McMahon <denismfmcmahon@gmail.com> - 2013-08-31 01:28 +0000
                    Re: calling a value into another php script... The Natural Philosopher <tnp@invalid.invalid> - 2013-08-31 03:55 +0100
                      Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-30 23:02 -0400
          Re: calling a value into another php script... Christoph Michael Becker <cmbecker69@arcor.de> - 2013-08-31 00:10 +0200
            Re: calling a value into another php script... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-31 01:06 +0200
              Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-30 20:39 -0400
              Re: calling a value into another php script... Christoph Michael Becker <cmbecker69@arcor.de> - 2013-09-01 20:10 +0200
                Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-01 15:19 -0400
              Re: calling a value into another php script... Twayne <nobody@spamcop.net> - 2013-09-02 15:13 -0400
            Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-30 20:37 -0400
      Re: calling a value into another php script... The Natural Philosopher <tnp@invalid.invalid> - 2013-08-30 02:50 +0100
        Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-29 22:18 -0400
        Re: calling a value into another php script... Twayne <nobody@spamcop.net> - 2013-08-30 17:24 -0400
          Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-30 20:41 -0400
      Re: calling a value into another php script... Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-29 21:50 -0400
    Re: calling a value into another php script... Norman Peelman <npeelman@cfl.rr.com> - 2013-08-31 07:00 -0400

Page 1 of 2  [1] 2  Next page →

#10643 — calling a value into another php script...

Hi all,

I am using an index.html to execute a php prog. First I am choosing a an option from a dropdown list, which will connect to a mail server. If the password is correct then it will open second html page. I want to call the code part into the 
second html page. How can it be done? 

<form action=xyz.php method=POST>
<option selected>Select from list</option>
<option value="x23@xyz.com">name1,code1</option>
<option value="y13@xyz.com">name2,code2</option>
<option value="z33@xyz.com">name3,code3</option>


thank you.

[toc] | [next] | [standalone]

#10644

On 8/28/2013 9:35 PM, nag wrote:
> Hi all,
>
> I am using an index.html to execute a php prog. First I am choosing a an option from a dropdown list, which will connect to a mail server. If the password is correct then it will open second html page. I want to call the code part into the
> second html page. How can it be done?
>
> <form action=xyz.php method=POST>
> <option selected>Select from list</option>
> <option value="x23@xyz.com">name1,code1</option>
> <option value="y13@xyz.com">name2,code2</option>
> <option value="z33@xyz.com">name3,code3</option>
>
>
> thank you.
>

Not enough information for an intelligent response.

Where is the password entered?  If it's in the same form, you need to 
validate the password in your script before calling the mail server.

And what mail server are you using?  Most do not have a web interface, 
but you have to look at the mail server interface to see how it works.

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

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

#10646

On Thursday, 29 August 2013 08:26:50 UTC+5:30, Jerry Stuckle  wrote:
> On 8/28/2013 9:35 PM, nag wrote:
> 
> > Hi all,
> 
> >
> 
> > I am using an index.html to execute a php prog. First I am choosing a an option from a dropdown list, which will connect to a mail server. If the password is correct then it will open second html page. I want to call the code part into the
> 
> > second html page. How can it be done?
> 
> >
> 
> > <form action=xyz.php method=POST>
> 
> > <option selected>Select from list</option>
> 
> > <option value="x23@xyz.com">name1,code1</option>
> 
> > <option value="y13@xyz.com">name2,code2</option>
> 
> > <option value="z33@xyz.com">name3,code3</option>
> 
> >
> 
> >
> 
> > thank you.
> 
> >
> 
> 
> 
> Not enough information for an intelligent response.
> 
> 
> 
> Where is the password entered?  If it's in the same form, you need to 
> 
> validate the password in your script before calling the mail server.
> 
> 
> 
> And what mail server are you using?  Most do not have a web interface, 
> 
> but you have to look at the mail server interface to see how it works.
> 
> 
> 
> -- 
> 
> ==================
> 
> Remove the "x" from my email address
> 
> Jerry Stuckle
> 
> JDS Computer Training Corp.
> 
> jstucklex@attglobal.net
> 
> ==================

We are using intranet. Its pop3 mail server. 
calling as 

<form action=passwd.php method=POST>


> Where is the password entered?  If it's in the same form, you need to 
> 
> validate the password in your script before calling the mail server.

 
    <tr>
      <td width="131" height="22" bordercolor="#999999" align="left">
      <font face="Verdana" color="white" size="2"><B>Password</font></td>
      <td width="148" height="22" bordercolor="ffffe0"><font face="Verdana">
      <input type="password" size="20" value name="passwd" style="background-color: ffe6c1; font-family:Verdana; font-size:8pt; color:#111111; font-weight:bold"></font></td>
    </tr>
  </table>
    <p><br>
  <input name="mailserver" type=hidden value="xx.xx.x.xx"> </p>
  <input type=submit value=Login name=submit> </p>
  </center>
</div>
 
Actually the username part in email id is itself the code part which I have to print on the second html page. Presently I am asking the user to enter the value. It is leading to do mistake by the user.

Thank you.

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

#10647

On 8/29/2013 9:06 AM, nag wrote:
> On Thursday, 29 August 2013 08:26:50 UTC+5:30, Jerry Stuckle  wrote:
>> On 8/28/2013 9:35 PM, nag wrote:
>>
>>> Hi all,
>>
>>>
>>
>>> I am using an index.html to execute a php prog. First I am choosing a an option from a dropdown list, which will connect to a mail server. If the password is correct then it will open second html page. I want to call the code part into the
>>
>>> second html page. How can it be done?
>>
>>>
>>
>>> <form action=xyz.php method=POST>
>>
>>> <option selected>Select from list</option>
>>
>>> <option value="x23@xyz.com">name1,code1</option>
>>
>>> <option value="y13@xyz.com">name2,code2</option>
>>
>>> <option value="z33@xyz.com">name3,code3</option>
>>
>>>
>>
>>>
>>
>>> thank you.
>>
>>>
>>
>>
>>
>> Not enough information for an intelligent response.
>>
>>
>>
>> Where is the password entered?  If it's in the same form, you need to
>>
>> validate the password in your script before calling the mail server.
>>
>>
>>
>> And what mail server are you using?  Most do not have a web interface,
>>
>> but you have to look at the mail server interface to see how it works.
>>
>>
>
> We are using intranet. Its pop3 mail server.
> calling as
>
> <form action=passwd.php method=POST>
>

This does not call the pop3 mail server.  Or am I misunderstanding what 
you mean?

>
>> Where is the password entered?  If it's in the same form, you need to
>>
>> validate the password in your script before calling the mail server.
>
>
>      <tr>
>        <td width="131" height="22" bordercolor="#999999" align="left">
>        <font face="Verdana" color="white" size="2"><B>Password</font></td>
>        <td width="148" height="22" bordercolor="ffffe0"><font face="Verdana">
>        <input type="password" size="20" value name="passwd" style="background-color: ffe6c1; font-family:Verdana; font-size:8pt; color:#111111; font-weight:bold"></font></td>
>      </tr>
>    </table>
>      <p><br>
>    <input name="mailserver" type=hidden value="xx.xx.x.xx"> </p>
>    <input type=submit value=Login name=submit> </p>
>    </center>
> </div>
>
> Actually the username part in email id is itself the code part which I have to print on the second html page. Presently I am asking the user to enter the value. It is leading to do mistake by the user.
>
> Thank you.
>

NEVER trust ANYTHING from the user - even hidden fields.  They can too 
easily be hacked (nothing says the information came from YOUR page - it 
can easily be faked).  This is especially true for things like email ids 
and email addresses.

And the fact this is an intranet is immaterial.

If you want to pass something from one page to another, then use the 
$_SESSION superglobal.


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

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

#10648

nag wrote:

> On Thursday, 29 August 2013 08:26:50 UTC+5:30, Jerry Stuckle  wrote:
>> […]

Please trim your quotes to the *relevant* *minimum*.

> We are using intranet. Its pop3 mail server.
> calling as
> 
> <form action=passwd.php method=POST>

POP3 is used to receive e-mails; SMTP is used to send e-mails.
 
>> Where is the password entered?  If it's in the same form, you need to
>> validate the password in your script before calling the mail server.
> 
>  
>     <tr>
>       <td width="131" height="22" bordercolor="#999999" align="left">
>       <font face="Verdana" color="white" size="2"><B>Password</font></td>
>       <td width="148" height="22" bordercolor="ffffe0"><font
>       face="Verdana"> <input type="password" size="20" value name="passwd"
>       style="background-color: ffe6c1; font-family:Verdana; font-size:8pt;
>       color:#111111; font-weight:bold"></font></td>
>     </tr>
>   </table>
>     <p><br>
>   <input name="mailserver" type=hidden value="xx.xx.x.xx"> </p>
>   <input type=submit value=Login name=submit> </p>
>   </center>
> </div>
>  
> Actually the username part in email id is itself the code part which I
> have to print on the second html page. Presently I am asking the user to
> enter the value. It is leading to do mistake by the user.

Still zero lines of PHP code posted, but HTML code that, if read, poses a 
severe risk for gtting eye cancer.  Perhaps you want to get the basics 
first?

<http://validator.w3.org/>
<http://php.net/manual/>
 
> Thank you.

You're welcome.


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

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

#10645

nag wrote:

> I am using an index.html to execute a php prog. First I am choosing a an
> option from a dropdown list, which will connect to a mail server. If the
> password is correct then it will open second html page. I want to call the
> code part into the second html page. How can it be done?

RTFM.
 
> <form action=xyz.php method=POST>
> <option selected>Select from list</option>
> <option value="x23@xyz.com">name1,code1</option>
> <option value="y13@xyz.com">name2,code2</option>
> <option value="z33@xyz.com">name3,code3</option>

You do not want to do that.


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

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

#10649

On 2013-08-28 9:35 PM, nag wrote:
> Hi all,
>
> I am using an index.html to execute a php prog. First I am choosing a an option from a

  >dropdown list, which will connect to a mail server. If the password 
is correct then it will open

>?second html page. I want to call the code part into the

> second html page. How can it be done?
>
> <form action=xyz.php method=POST>
> <option selected>Select from list</option>
> <option value="x23@xyz.com">name1,code1</option>
> <option value="y13@xyz.com">name2,code2</option>
> <option value="z33@xyz.com">name3,code3</option>
>
>
> thank you.
>

I'm not sure, but you might want to use an href for the file you want to 
open. As already mentioned, your info is a little lacking in detail; 
actual code would be better to look at.

Also you should set your line lengths in your nntp client to be 80 
characters or less in length. Over-length lines often won't all a 
response until they're broken up as I did above.

And while I'm at it, you can pretty  much ignore Stuckle; he's more of a 
troll than anything else and very, very seldom parts with any useful 
information, if he actually has any.

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

#10650

Twayne wrote:

> I'm not sure, but you might want to use an href for the file you want to
> open. As already mentioned, your info is a little lacking in detail;
> actual code would be better to look at.

ACK.

> Also you should set your line lengths in your nntp client to be 80
> characters or less in length. Over-length lines often won't all a
> response until they're broken up as I did above.

ACK.  However, that might not be easily accomplished by posting via
Google groups.

> And while I'm at it, you can pretty  much ignore Stuckle; he's more of a
> troll than anything else and very, very seldom parts with any useful
> information, if he actually has any.

One may consider Jerry opinionated--but one should better not fall to
the fallacy to consider him clueless.  On the contrary, he can give
valuable hints if one asks the "right" questions.  And even if one asks
"wrong" questions here, Jerry might give valuable hints; for instance,
to look for a more suitable newsgroup/forum.

-- 
Christoph M. Becker

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

#10653

On 30/08/13 01:57, Christoph Michael Becker wrote:
> Twayne wrote:
>
>> I'm not sure, but you might want to use an href for the file you want to
>> open. As already mentioned, your info is a little lacking in detail;
>> actual code would be better to look at.
> ACK.
>
>> Also you should set your line lengths in your nntp client to be 80
>> characters or less in length. Over-length lines often won't all a
>> response until they're broken up as I did above.
> ACK.  However, that might not be easily accomplished by posting via
> Google groups.
>
>> And while I'm at it, you can pretty  much ignore Stuckle; he's more of a
>> troll than anything else and very, very seldom parts with any useful
>> information, if he actually has any.
> One may consider Jerry opinionated--but one should better not fall to
> the fallacy to consider him clueless.  On the contrary, he can give
> valuable hints if one asks the "right" questions.  And even if one asks
> "wrong" questions here, Jerry might give valuable hints; for instance,
> to look for a more suitable newsgroup/forum.
>
If you think that's valuable, you have a funny idea of value.

I hope the next time yoursatnav is broken  and you stop to ask someone 
the way the conversation goes like this

'Excuse me, can you tell me the way to San Jose?'
'No, I am a postman and my name is Stuckle.Try the post office'.
'So how do I get to the post office?'
'I am only a postman. Its not ,my job to tell you how to find the post 
office'



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

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

#10661

...

   And even if one asks
>> "wrong" questions here, Jerry might give valuable hints; for instance,
>> to look for a more suitable newsgroup/forum.

Sounds like good self-advice.
>>
> If you think that's valuable, you have a funny idea of value.
>
> I hope the next time yoursatnav is broken  and you stop to ask someone
> the way the conversation goes like this
>
> 'Excuse me, can you tell me the way to San Jose?'
> 'No, I am a postman and my name is Stuckle.Try the post office'.
> 'So how do I get to the post office?'
> 'I am only a postman. Its not ,my job to tell you how to find the post
> office'

LOL!!  That's got to be the best analogy I've see in a LONG time!  I 
don't dislike him; he's easy enough to avoid/ignore; I just think he's 
more a troll than anything else.

>
>
>

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

#10656

Christoph Michael Becker wrote:

> Twayne wrote:
>> And while I'm at it, you can pretty  much ignore Stuckle; he's more of a
>> troll than anything else and very, very seldom parts with any useful
>> information, if he actually has any.
> 
> One may consider Jerry opinionated--but one should better not fall to
> the fallacy to consider him clueless.  On the contrary, he can give
> valuable hints if one asks the "right" questions. 

(This concerns all, so no reply via e-mail this time.)

Like actually recommending to *disable* output buffering on a production 
site, when having output buffering *enabled* is *the* *proven*, simple 
measure to make a PHP-powered site faster, thus more user-friendly.

<news:ku1e26$5a9$3@dont-email.me>

vs.

,-[default php.ini]
| 
| ; output_buffering
| ;   Default Value: Off
| ;   Development Value: 4096
| ;   Production Value: 4096

And that is just one of many examples where he is – probably out of lack of 
*real* *PHP* *development* experience – dead wrong, while the majority of 
his postings are nothing more than calling someone else troll.

(Q: If he realized it was a troll, why would he not just *stop* *feeding* 
them?  A: It takes one to know one.)

So thanks, but no, thanks.  This newsgroup is much more readable for me 
without his postings.  Should he post anything valuable, which I consider 
highly unlikely at this point, I will be reading it in quotations.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

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

#10657

On 8/30/2013 5:57 AM, Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> Twayne wrote:
>>> And while I'm at it, you can pretty  much ignore Stuckle; he's more of a
>>> troll than anything else and very, very seldom parts with any useful
>>> information, if he actually has any.
>>
>> One may consider Jerry opinionated--but one should better not fall to
>> the fallacy to consider him clueless.  On the contrary, he can give
>> valuable hints if one asks the "right" questions.
>
> (This concerns all, so no reply via e-mail this time.)
>
> Like actually recommending to *disable* output buffering on a production
> site, when having output buffering *enabled* is *the* *proven*, simple
> measure to make a PHP-powered site faster, thus more user-friendly.
>
> <news:ku1e26$5a9$3@dont-email.me>
>
> vs.
>
> ,-[default php.ini]
> |
> | ; output_buffering
> | ;   Default Value: Off
> | ;   Development Value: 4096
> | ;   Production Value: 4096
>
> And that is just one of many examples where he is – probably out of lack of
> *real* *PHP* *development* experience – dead wrong, while the majority of
> his postings are nothing more than calling someone else troll.
>

Proven by whom?  You?  ROFLMAO!

The actual proof is that it adds additional overhead to the server, 
requiring additional memory and cpu to perform the buffering.

The system already does some of its own buffering - where buffering 
makes sense.  PHP buffers output before it is sent to the server, and 
the server buffers output before it is sent to the user.  But these are 
at measured points, not just buffering everything.

> (Q: If he realized it was a troll, why would he not just *stop* *feeding*
> them?  A: It takes one to know one.)
>

So sayeth the guy who is known as a troll by thousands of usenet users 
in multiple newsgroups!

> So thanks, but no, thanks.  This newsgroup is much more readable for me
> without his postings.  Should he post anything valuable, which I consider
> highly unlikely at this point, I will be reading it in quotations.
>
>
> PointedEars
>

How about this: You, Twayne and TNP leave and let people who actually 
understand PHP answer questions in this newsgroup.  Then it would be 
better for EVERYONE.

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

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

#10658

On Fri, 30 Aug 2013 08:49:14 -0400, Jerry Stuckle wrote:

> On 8/30/2013 5:57 AM, Thomas 'The PointedEars Twat' Lahn wrote:

>> Like actually recommending to *disable* output buffering on a
>> production site, when having output buffering *enabled* is *the*
>> *proven*, simple measure to make a PHP-powered site faster, thus more
>> user-friendly.

The only benefit I've ever seen from PHP output buffering is it allows 
you to output a page and then change the headers at the end if for some 
reason you have a need to ... as long as the buffer was big enough to 
hold the whole page, otherwise you're fucked anyway, which is probably 
why sensible coders always make sure they send all the headers *before* 
sending the output.

Anyway, as you say, the browser is probably buffering the page, 
especially if it's using compression, so all that buffering in php will 
do is increase the memory footprint of the process.

This may in some cases mean that the output is "buffered" in the script, 
by which I mean you build the output as a variable, or possibly a 
collection of variables and an:

echo <<< EOT

......

EOT;

where you insert those variables into the output, but IME it is better to 
make sure that you get the whole headers before data thing right, rather 
than rely on buffering and the "I wonder if tweaking this parameter will 
reduce my memory footprint" whims of a future site administrator to do it 
for you.

Especially as the future site admin is probably going to be a new hire 
they recruited in a panic when the old unix admin retired, is probably 
fresh out of college, and has no idea about real world IT.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#10659

On 8/30/2013 10:30 AM, Denis McMahon wrote:
> On Fri, 30 Aug 2013 08:49:14 -0400, Jerry Stuckle wrote:
>
>> On 8/30/2013 5:57 AM, Thomas 'The PointedEars Twat' Lahn wrote:
>
>>> Like actually recommending to *disable* output buffering on a
>>> production site, when having output buffering *enabled* is *the*
>>> *proven*, simple measure to make a PHP-powered site faster, thus more
>>> user-friendly.
>
> The only benefit I've ever seen from PHP output buffering is it allows
> you to output a page and then change the headers at the end if for some
> reason you have a need to ... as long as the buffer was big enough to
> hold the whole page, otherwise you're fucked anyway, which is probably
> why sensible coders always make sure they send all the headers *before*
> sending the output.
>

I've also used it when calling code which outputs directly, so I can 
parse that output.  For instance, if you want to know the current 
configuration, you can buffer the output of phpinfo(INFO_CONFIGURATION), 
then parse it.  It's easier to do than to figure out all of the 
configuration parameters yourself.  Of course, if you only want one or 
two, then just using ini_get() would be easier.

But you're right - it's always best to just send the correct headers 
first, then output your data.

> Anyway, as you say, the browser is probably buffering the page,
> especially if it's using compression, so all that buffering in php will
> do is increase the memory footprint of the process.
>

Yes, the browser buffers the output - but PHP also buffers the output 
before sending it to the web server for efficiency.  Buffering it 
yourself has no gain.  And the web server will buffer the output so it 
can break it into the appropriate sized packets.  Buffering it yourself 
just adds an extra layer of overhead - the PHP buffer size doesn't 
change, so you will end up with the same number of buffer fills and 
sends to the server, and the packet size doesn't change so the same 
number of packets will be sent.

> This may in some cases mean that the output is "buffered" in the script,
> by which I mean you build the output as a variable, or possibly a
> collection of variables and an:
>
> echo <<< EOT
>
> ......
>
> EOT;
>
> where you insert those variables into the output, but IME it is better to
> make sure that you get the whole headers before data thing right, rather
> than rely on buffering and the "I wonder if tweaking this parameter will
> reduce my memory footprint" whims of a future site administrator to do it
> for you.
>
> Especially as the future site admin is probably going to be a new hire
> they recruited in a panic when the old unix admin retired, is probably
> fresh out of college, and has no idea about real world IT.
>

Exactly.

Buffering it yourself is OK when you get 100 hits/day.  But try a site 
that peaks at > 1K hits/second and you'll definitely see a difference 
(and not for the better!).

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

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

#10664

Jerry Stuckle wrote:

> On 8/30/2013 10:30 AM, Denis McMahon wrote:
>> On Fri, 30 Aug 2013 08:49:14 -0400, Jerry Stuckle wrote:
>>
>>> On 8/30/2013 5:57 AM, Thomas 'The PointedEars Twat' Lahn wrote:
                                                  ^^^^ IMO that's
neither helpful nor funny.

>>>> Like actually recommending to *disable* output buffering on a
>>>> production site, when having output buffering *enabled* is *the*
>>>> *proven*, simple measure to make a PHP-powered site faster, thus more
>>>> user-friendly.
>>
>> The only benefit I've ever seen from PHP output buffering is it allows
>> you to output a page and then change the headers at the end if for some
>> reason you have a need to ... as long as the buffer was big enough to
>> hold the whole page, otherwise you're fucked anyway, which is probably
>> why sensible coders always make sure they send all the headers *before*
>> sending the output.
>>
> 
> I've also used it when calling code which outputs directly, so I can
> parse that output.  For instance, if you want to know the current
> configuration, you can buffer the output of phpinfo(INFO_CONFIGURATION),
> then parse it.  It's easier to do than to figure out all of the
> configuration parameters yourself.  Of course, if you only want one or
> two, then just using ini_get() would be easier.
> 
> But you're right - it's always best to just send the correct headers
> first, then output your data.
> 
>> Anyway, as you say, the browser is probably buffering the page,
>> especially if it's using compression, so all that buffering in php will
>> do is increase the memory footprint of the process.

What the browser does is completely unrelated to the issue at
hand--we're talking about the server side.

Setting output_buffering=4096 will indeed increase the memory footprint
of the process--by 4 KByte!  That seems to be an awful lot these days. ;)

> Yes, the browser buffers the output - but PHP also buffers the output
> before sending it to the web server for efficiency.

That depends on the ini setting of output_buffering--exactly what's the
issue at hand.

>                                                      Buffering it
> yourself has no gain.  And the web server will buffer the output so it
> can break it into the appropriate sized packets.  Buffering it yourself
> just adds an extra layer of overhead - the PHP buffer size doesn't
> change, so you will end up with the same number of buffer fills and
> sends to the server, and the packet size doesn't change so the same
> number of packets will be sent.

What you're talking about here seems to be the usage of the ob_*() set
of functions.  Indeed, using these might not be the best idea, *generally*.

-- 
Christoph M. Becker

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

#10667

On 8/30/2013 6:19 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 8/30/2013 10:30 AM, Denis McMahon wrote:
>>> On Fri, 30 Aug 2013 08:49:14 -0400, Jerry Stuckle wrote:
>>>
>>>> On 8/30/2013 5:57 AM, Thomas 'The PointedEars Twat' Lahn wrote:
>                                                    ^^^^ IMO that's
> neither helpful nor funny.
>

Not my posting.  Please learn to reply to the appropriate person when 
commenting posts.

BTW - I don't think it was meant to be either helpful or funny - but it 
is accurate.

>>>>> Like actually recommending to *disable* output buffering on a
>>>>> production site, when having output buffering *enabled* is *the*
>>>>> *proven*, simple measure to make a PHP-powered site faster, thus more
>>>>> user-friendly.
>>>
>>> The only benefit I've ever seen from PHP output buffering is it allows
>>> you to output a page and then change the headers at the end if for some
>>> reason you have a need to ... as long as the buffer was big enough to
>>> hold the whole page, otherwise you're fucked anyway, which is probably
>>> why sensible coders always make sure they send all the headers *before*
>>> sending the output.
>>>
>>
>> I've also used it when calling code which outputs directly, so I can
>> parse that output.  For instance, if you want to know the current
>> configuration, you can buffer the output of phpinfo(INFO_CONFIGURATION),
>> then parse it.  It's easier to do than to figure out all of the
>> configuration parameters yourself.  Of course, if you only want one or
>> two, then just using ini_get() would be easier.
>>
>> But you're right - it's always best to just send the correct headers
>> first, then output your data.
>>
>>> Anyway, as you say, the browser is probably buffering the page,
>>> especially if it's using compression, so all that buffering in php will
>>> do is increase the memory footprint of the process.
>
> What the browser does is completely unrelated to the issue at
> hand--we're talking about the server side.
>
> Setting output_buffering=4096 will indeed increase the memory footprint
> of the process--by 4 KByte!  That seems to be an awful lot these days. ;)
>

Which is completely immaterial because that's not the buffering we are 
discussing.

>> Yes, the browser buffers the output - but PHP also buffers the output
>> before sending it to the web server for efficiency.
>
> That depends on the ini setting of output_buffering--exactly what's the
> issue at hand.
>

No, please read again - and understand what Pointed Head claimed.  It 
has absolutely nothing to do with the ini setting of output_buffering.

>>                                                       Buffering it
>> yourself has no gain.  And the web server will buffer the output so it
>> can break it into the appropriate sized packets.  Buffering it yourself
>> just adds an extra layer of overhead - the PHP buffer size doesn't
>> change, so you will end up with the same number of buffer fills and
>> sends to the server, and the packet size doesn't change so the same
>> number of packets will be sent.
>
> What you're talking about here seems to be the usage of the ob_*() set
> of functions.  Indeed, using these might not be the best idea, *generally*.
>

Exactly - which is what Pointed Head was proposing.

Please try to understand what is being said before contradicting it.

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

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

#10671

On 8/30/2013 8:33 PM, Jerry Stuckle wrote:
> On 8/30/2013 6:19 PM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
>>
>>> On 8/30/2013 10:30 AM, Denis McMahon wrote:
>>>> On Fri, 30 Aug 2013 08:49:14 -0400, Jerry Stuckle wrote:
>>>>
>>>>> On 8/30/2013 5:57 AM, Thomas 'The PointedEars Twat' Lahn wrote:
>>                                                    ^^^^ IMO that's
>> neither helpful nor funny.
>>
>
> Not my posting.  Please learn to reply to the appropriate person when
> commenting posts.
>
> BTW - I don't think it was meant to be either helpful or funny - but it
> is accurate.
>
>>>>>> Like actually recommending to *disable* output buffering on a
>>>>>> production site, when having output buffering *enabled* is *the*
>>>>>> *proven*, simple measure to make a PHP-powered site faster, thus more
>>>>>> user-friendly.
>>>>
>>>> The only benefit I've ever seen from PHP output buffering is it allows
>>>> you to output a page and then change the headers at the end if for some
>>>> reason you have a need to ... as long as the buffer was big enough to
>>>> hold the whole page, otherwise you're fucked anyway, which is probably
>>>> why sensible coders always make sure they send all the headers *before*
>>>> sending the output.
>>>>
>>>
>>> I've also used it when calling code which outputs directly, so I can
>>> parse that output.  For instance, if you want to know the current
>>> configuration, you can buffer the output of phpinfo(INFO_CONFIGURATION),
>>> then parse it.  It's easier to do than to figure out all of the
>>> configuration parameters yourself.  Of course, if you only want one or
>>> two, then just using ini_get() would be easier.
>>>
>>> But you're right - it's always best to just send the correct headers
>>> first, then output your data.
>>>
>>>> Anyway, as you say, the browser is probably buffering the page,
>>>> especially if it's using compression, so all that buffering in php will
>>>> do is increase the memory footprint of the process.
>>
>> What the browser does is completely unrelated to the issue at
>> hand--we're talking about the server side.
>>
>> Setting output_buffering=4096 will indeed increase the memory footprint
>> of the process--by 4 KByte!  That seems to be an awful lot these days. ;)
>>
>
> Which is completely immaterial because that's not the buffering we are
> discussing.
>
>>> Yes, the browser buffers the output - but PHP also buffers the output
>>> before sending it to the web server for efficiency.
>>
>> That depends on the ini setting of output_buffering--exactly what's the
>> issue at hand.
>>
>
> No, please read again - and understand what Pointed Head claimed.  It
> has absolutely nothing to do with the ini setting of output_buffering.
>
>>>                                                       Buffering it
>>> yourself has no gain.  And the web server will buffer the output so it
>>> can break it into the appropriate sized packets.  Buffering it yourself
>>> just adds an extra layer of overhead - the PHP buffer size doesn't
>>> change, so you will end up with the same number of buffer fills and
>>> sends to the server, and the packet size doesn't change so the same
>>> number of packets will be sent.
>>
>> What you're talking about here seems to be the usage of the ob_*() set
>> of functions.  Indeed, using these might not be the best idea,
>> *generally*.
>>
>
> Exactly - which is what Pointed Head was proposing.
>
> Please try to understand what is being said before contradicting it.
>

My apologies - I read back through this thread and realized you don't 
have the background of the previous discussions Pointed Head is talking 
about.

He has propounded that buffering in the script (generally using the 
ob_xxx() calls) is more efficient than outputting the data directly.

It has nothing to do with the PHP buffering, which I agree is handled 
well (like I said in my first response to him).

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

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

#10696

Jerry Stuckle wrote:

> On 8/30/2013 8:33 PM, Jerry Stuckle wrote:
>>
>> Not my posting.  Please learn to reply to the appropriate person when
>> commenting posts.

Indeed, you didn't post this attribution line, but it was quoted this
way in the post I was replying to.

>> BTW - I don't think it was meant to be either helpful or funny - but it
>> is accurate.

> My apologies - I read back through this thread and realized you don't
> have the background of the previous discussions Pointed Head is talking
> about.

If you're referring to older discussions (say about a year back, or
longer), indeed, I don't have the background.

> He has propounded that buffering in the script (generally using the
> ob_xxx() calls) is more efficient than outputting the data directly.
> 
> It has nothing to do with the PHP buffering, which I agree is handled
> well (like I said in my first response to him).

There still seems to be a misunderstanding.  In *this* thread Thomas was
referring to PHP's output_buffering, not to the ob_*() functions.

-- 
Christoph M. Becker

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

#10697

On 9/1/2013 2:23 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 8/30/2013 8:33 PM, Jerry Stuckle wrote:
>>>
>>> Not my posting.  Please learn to reply to the appropriate person when
>>> commenting posts.
>
> Indeed, you didn't post this attribution line, but it was quoted this
> way in the post I was replying to.
>
>>> BTW - I don't think it was meant to be either helpful or funny - but it
>>> is accurate.
>
>> My apologies - I read back through this thread and realized you don't
>> have the background of the previous discussions Pointed Head is talking
>> about.
>
> If you're referring to older discussions (say about a year back, or
> longer), indeed, I don't have the background.
>
>> He has propounded that buffering in the script (generally using the
>> ob_xxx() calls) is more efficient than outputting the data directly.
>>
>> It has nothing to do with the PHP buffering, which I agree is handled
>> well (like I said in my first response to him).
>
> There still seems to be a misunderstanding.  In *this* thread Thomas was
> referring to PHP's output_buffering, not to the ob_*() functions.
>

No, if you were familiar with Pointed Head's previous postings, he was 
referring to buffering in the script - not PHP buffering - using 
ob_xxx() functions or even putting everything into a string.

He doesn't even know about PHP buffering - although he will claim to the 
end of the world he wrote code that does it.

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

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

#10672

On Sat, 31 Aug 2013 00:19:48 +0200, Christoph Michael Becker wrote:

>>> Anyway, as you say, the browser is probably buffering the page,
>>> especially if it's using compression, so all that buffering in php
>>> will do is increase the memory footprint of the process.
> 
> What the browser does is completely unrelated to the issue at
> hand--we're talking about the server side.

Yes, freudian slip, typed browser when I meant web server process, so sue 
me.

And TPEL is the most anally retentive twat I have ever come across on 
usenet, even if you don't find my saying so helpful. I have never seen 
him make a constructive comment, I have only ever seen him criticise the 
input of others.

In that respect he's worse than TNP, Twayne, Richard the stoopid and the 
bigoted idiot that uses broken html on the basis it renders ok and then 
whines when his overlong broken pages overflow the ability of browsers to 
cope with his element nesting errors.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web