NEOHAPSIS - Peace of Mind Through Integrity and Insight

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

Neohapsis > Archives > PHP Discussion Digest> 2008-01

php-general Digest 1 Feb 2008 08:13:26 -0000 Issue 5268

php-general-digest-helplists.php.net
Date: Fri Feb 01 2008 - 02:13:26 CST

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

php-general Digest 1 Feb 2008 08:13:26 -0000 Issue 5268

Topics (messages 268486 through 268518):

Re: disable referer ? (was: Framed & Linked Content)
        268486 by: Per Jessen
        268487 by: Robert Cummings
        268488 by: Per Jessen
        268489 by: Andrew Ballard
        268490 by: Andrew Ballard
        268491 by: Robert Cummings
        268492 by: Robert Cummings
        268493 by: Per Jessen
        268494 by: Per Jessen
        268495 by: Robert Cummings
        268497 by: Per Jessen
        268499 by: Robert Cummings

Re: Strtotime returns 02/09/2008 for "next Saturday"....
        268496 by: Mike Morton
        268501 by: Jochem Maas
        268506 by: Richard Lynch

Re: [Slightly OT] Apple MacBook MAMP and Logic
        268498 by: Colin Guthrie
        268500 by: Tom Chubb
        268509 by: Brady Mitchell

Re: Need assistance using sendmail or mail()
268502 by: Richard Lynch

Re: PEAR website and MSIE 6
        268503 by: Richard Lynch
        268505 by: Daevid Vincent
        268507 by: Richard Lynch
        268508 by: Daevid Vincent
        268511 by: Jochem Maas
        268512 by: mike

Re: how do you get to do multiple mysql queries concurrently?
268504 by: Richard Lynch

Re: first php 5 class
268510 by: Greg Donald

Re: how dod you get to do multiple mysql queries concurrently?
268513 by: Jochem Maas
268515 by: Paul Scott

array iteration vs. ArrayIterator
268514 by: Nathan Nobbe

Release candidate: Chisimba-2.0.0RC1
268516 by: Paul Scott

mysqli_embedded_server_start
268517 by: Kyohere Luke
268518 by: Per Jessen

Administrivia:

To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net

To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net

To post to the list, e-mail:
php-generallists.php.net

----------------------------------------------------------------------

attached mail follows:

Eric Butera wrote:

>
> The fact it can be tampered with should be enough to ignore it, right?
>

Well, no. _anything_ can be tampered with given the right amount of
resources. For instance, exactly _when_ an otherwise unbreakable
encryption is borken is _only_ a matter of money. How far you go in
securing content (or whatever) is purely a matter of how far someone
will go in an attempt to overcome your security.

To get back on topic, if you're insanely paranoid about people getting
access to your content by direct remote links, of course you can't rely
on REFERER and you'll have to use a more complex scheme.
Otherwise, when you do rely on REFERER, 1) you will be shutting out
other insanely paranoid people who do not provide a REFERER and 2) you
leave your content available to individuals who forge the REFERER.

Personally I think 1) is good and 2) is acceptable.

/Per Jessen, ZÃ¼rich

attached mail follows:

On Thu, 2008-01-31 at 20:24 +0100, Per Jessen wrote:
> Richard Lynch wrote:
>
> >>> It CANNOT be tied to the IP address, because most users' IP
> >>> addresses are not static.
> >>
> >> I think it is for the duration of the session. Mine certainly is.
> >
> > Yours might be.
> > AOL users are *NOT*.
> > In peak periods, an AOL users' IP address with change with every HTTP
> > request.
>
> Surely you are joking?? Don't they use DHCP for dishing out addresses?
> I guess AOL users just have to do without https during peak hours :-)
>
> > Further, large corporate users will ALL appear as a single IP address.
>
> Yes, that's assuming they're using NAT - which many small and large
> entities will be, I agree. In such cases, if the session id _is_
> somehow tied to the IP-address, any attempt to hijack the session from
> outside the NAT'ed network will fail.
>
> >> Regardless, I did some googling and read a bit about session
> >> hijacking and such. I still don't see much of a serious problem.
> >> When Firefox switches off REFERER by default, we can talk again.
> >
> > Suppose only 0.1% of the Internet users have REFERER off.
> >
> > You say "That's not much. 0.1%"
> >
> > Now suppose there are a billion people who use the Internet.
> >
> > What is 0.1% of a billion?
> >
> > Do the math.
>
> 10million. But what I said was that _maybe_ 0.00X% have REFERER
> switched off - and 0.001% of 1billion is 10.000 people. I can live
> with that.
>
> > If you have even a few thousand visitors, you are likely getting at
> > least a few that have no REFERER...
>
> Like I said, I can live with that. If people are that paranoid, they
> shouldn't be on the internet at all, IMHO.

Not just people. Many firewalls either strip or modify the referrer.
Information leakage is a security issue. IMHO referer logging should
need to be turned on, not off.

Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

attached mail follows:

Robert Cummings wrote:

> Information leakage is a security issue. IMHO referer logging should
> need to be turned on, not off.

Rob, I appreciate your opinion, but like I said - when Firefox (or MSIE)
switches off REFERER by default, we can talk again.

/Per Jessen, ZÃ¼rich

attached mail follows:

On Jan 31, 2008 2:24 PM, Per Jessen <percomputer.org> wrote:
> Richard Lynch wrote:
>
> >>> It CANNOT be tied to the IP address, because most users' IP
> >>> addresses are not static.
> >>
> >> I think it is for the duration of the session. Mine certainly is.
> >
> > Yours might be.
> > AOL users are *NOT*.
> > In peak periods, an AOL users' IP address with change with every HTTP
> > request.
>
> Surely you are joking?? Don't they use DHCP for dishing out addresses?
> I guess AOL users just have to do without https during peak hours :-)

No, that's not it. The AOL users do have a consistent IP to connect to
the AOL network during a given session. However, AOL routes their
traffic through proxy servers and you may or may not get the same
proxy with each request. It does seem to be more consistent than it
used to, but to the web server, it is very possible that each request
will come from a different IP. And I don't believe AOL uses the
X-Apparently-For (or whatever that header is) either.

> Like I said, I can live with that. If people are that paranoid, they
> shouldn't be on the internet at all, IMHO.

It's not just paranoia over having sessions hijacked. You could still
have sensitive data leaked from query string params that have nothing
to do with the session information, not to mention some people just
don't like telling every web site where they came from. There doesn't
have to be anything nefarious.

Personally, I haven't munged with my referer any, but I do think it
should be easier for users to choose whether it should be sent
regardless of which browser they are using.

Andrew

attached mail follows:

On Jan 31, 2008 2:49 PM, Per Jessen <percomputer.org> wrote:
> Robert Cummings wrote:
>
> > Information leakage is a security issue. IMHO referer logging should
> > need to be turned on, not off.
>
> Rob, I appreciate your opinion, but like I said - when Firefox (or MSIE)
> switches off REFERER by default, we can talk again.
>
>

It's been a long time, but I seem to recall there was a version of
either Netscape or IE (pretty mainstream) around v4 that did not send
it. I was setting up one of those wonderful little formmail scripts
that used REFERER to determine whether you were allowed to submit to
the form, and was bugged at why I kept getting messages saying I
wasn't authorized when I know I came from an "authorized" page. Turns
out, the value of REFERER was blank.

Andrew

attached mail follows:

On Thu, 2008-01-31 at 20:49 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> > Information leakage is a security issue. IMHO referer logging should
> > need to be turned on, not off.
>
> Rob, I appreciate your opinion, but like I said - when Firefox (or MSIE)
> switches off REFERER by default, we can talk again.

Lol, this is an open discussion. I post for all to read, not just you.

attached mail follows:

On Thu, 2008-01-31 at 15:10 -0500, Robert Cummings wrote:
> On Thu, 2008-01-31 at 20:49 +0100, Per Jessen wrote:
> > Robert Cummings wrote:
> >
> > > Information leakage is a security issue. IMHO referer logging should
> > > need to be turned on, not off.
> >
> > Rob, I appreciate your opinion, but like I said - when Firefox (or MSIE)
> > switches off REFERER by default, we can talk again.
>
> Lol, this is an open discussion. I post for all to read, not just you.

FWIW BTW, they will probably never switch it off for the same reason
Windows isn't locked down properly by default. Too many dumb users would
cry WTF and wouldn't understand the answer. As such the simplest
solution is to leave users exposed rather than educating them.

attached mail follows:

Andrew Ballard wrote:

>>> Yours might be.
>>> AOL users are *NOT*.
>>> In peak periods, an AOL users' IP address with change with every
>>> HTTP request.
>>
>> Surely you are joking?? Don't they use DHCP for dishing out
>> addresses? I guess AOL users just have to do without https during
>> peak hours :-)
>
> No, that's not it. The AOL users do have a consistent IP to connect to
> the AOL network during a given session. However, AOL routes their
> traffic through proxy servers and you may or may not get the same
> proxy with each request. It does seem to be more consistent than it
> used to, but to the web server, it is very possible that each request
> will come from a different IP. And I don't believe AOL uses the
> X-Apparently-For (or whatever that header is) either.

There is some or other header that is intended for making the target
server aware of proxying, but I can't remember what it is either.

>> Like I said, I can live with that. If people are that paranoid, they
>> shouldn't be on the internet at all, IMHO.
>
> It's not just paranoia over having sessions hijacked. You could still
> have sensitive data leaked from query string params that have nothing
> to do with the session information, not to mention some people just
> don't like telling every web site where they came from. There doesn't
> have to be anything nefarious.

Oh, I agree with that. To me it just still comes under the paranoia
heading. Wrt to "people just don't like telling every web site where
they came from", that's also a fair point. Then it's up to me as a
developer to determine if I can be bothered to cater to those too.
Especially when it only takes 2-3 lines of apache config to deal with
the 99.999% of my (less paranoid) users.

> Personally, I haven't munged with my referer any, but I do think it
> should be easier for users to choose whether it should be sent
> regardless of which browser they are using.

I think that's a fair request - how about an option for "omit REFERER
when changing websites only" ? Now, where's that Firefox wishlist?

/Per Jessen, ZÃ¼rich

attached mail follows:

Robert Cummings wrote:

> On Thu, 2008-01-31 at 15:10 -0500, Robert Cummings wrote:
>> On Thu, 2008-01-31 at 20:49 +0100, Per Jessen wrote:
>> > Robert Cummings wrote:
>> >
>> > > Information leakage is a security issue. IMHO referer logging
>> > > should need to be turned on, not off.
>> >
>> > Rob, I appreciate your opinion, but like I said - when Firefox (or
>> > MSIE) switches off REFERER by default, we can talk again.
>>
>> Lol, this is an open discussion. I post for all to read, not just
>> you.
>
> FWIW BTW, they will probably never switch it off for the same reason
> Windows isn't locked down properly by default. Too many dumb users
> would cry WTF and wouldn't understand the answer. As such the simplest
> solution is to leave users exposed rather than educating them.

I'm certain they'll never switch it off by default. Well, at least not
until we have a new HTTP spec that specifically deprecates REFERER.
I won't hold my breath :-)

/Per Jessen, ZÃ¼rich

attached mail follows:

On Thu, 2008-01-31 at 21:32 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> > On Thu, 2008-01-31 at 15:10 -0500, Robert Cummings wrote:
> >> On Thu, 2008-01-31 at 20:49 +0100, Per Jessen wrote:
> >> > Robert Cummings wrote:
> >> >
> >> > > Information leakage is a security issue. IMHO referer logging
> >> > > should need to be turned on, not off.
> >> >
> >> > Rob, I appreciate your opinion, but like I said - when Firefox (or
> >> > MSIE) switches off REFERER by default, we can talk again.
> >>
> >> Lol, this is an open discussion. I post for all to read, not just
> >> you.
> >
> > FWIW BTW, they will probably never switch it off for the same reason
> > Windows isn't locked down properly by default. Too many dumb users
> > would cry WTF and wouldn't understand the answer. As such the simplest
> > solution is to leave users exposed rather than educating them.
>
> I'm certain they'll never switch it off by default. Well, at least not
> until we have a new HTTP spec that specifically deprecates REFERER.
> I won't hold my breath :-)

Interesting you mention the HTTP spec...

14.36 Referer

   The Referer[sic] request-header field allows the client to specify,
   for the server's benefit, the address (URI) of the resource from
   which the Request-URI was obtained (the "referrer", although the
   header field is misspelled.) The Referer request-header allows a
   server to generate lists of back-links to resources for interest,
   logging, optimized caching, etc. It also allows obsolete or mistyped
   links to be traced for maintenance. The Referer field MUST NOT be
   sent if the Request-URI was obtained from a source that does not have
   its own URI, such as input from the user keyboard.

Referer = "Referer" ":" ( absoluteURI | relativeURI )

Example:

Referer: http://www.w3.org/hypertext/DataSources/Overview.html

   If the field value is a relative URI, it SHOULD be interpreted
   relative to the Request-URI. The URI MUST NOT include a fragment. See
   section 15.1.3 for security considerations.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

15.1.3 Encoding Sensitive Information in URI's

   Because the source of a link might be private information or might
   reveal an otherwise private information source, it is strongly
   recommended that the user be able to select whether or not the
   Referer field is sent. For example, a browser client could have a
   toggle switch for browsing openly/anonymously, which would
   respectively enable/disable the sending of Referer and From
   information.

   Clients SHOULD NOT include a Referer header field in a (non-secure)
   HTTP request if the referring page was transferred with a secure
   protocol.

   Authors of services which use the HTTP protocol SHOULD NOT use GET
   based forms for the submission of sensitive data, because this will
   cause this data to be encoded in the Request-URI. Many existing
   servers, proxies, and user agents will log the request URI in some
   place where it might be visible to third parties. Servers can use
   POST-based form submission instead

So at least the spec explicitly recommends allowing the user to set
whether the referrer is sent. As such, no site should rely on it.

attached mail follows:

Robert Cummings wrote:

> So at least the spec explicitly recommends allowing the user to set
> whether the referrer is sent. As such, no site should rely on it.

Agreed, in principle it should not be relied upon. But then neither
should MSIE[567] :-)

Besides, today Firefox and Opera both allow the user to set whether the
referrer is sent.
Until the default is changed to not to send it, I'll stick to using
REFERER. If/when the time comes, it's an easy change, and until then
it's no headache.

Anyway, thanks for some interesting points, Rob - I like an intelligent
response. Quoting the HTTP spec to me was good - I'll have to be a
little wary of you in the future :-)

/Per Jessen, ZÃ¼rich

attached mail follows:

On Thu, 2008-01-31 at 22:36 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> Anyway, thanks for some interesting points, Rob - I like an intelligent
> response. Quoting the HTTP spec to me was good - I'll have to be a
> little wary of you in the future :-)

I was just padding my end of week bytecount ;)

attached mail follows:

Good point ;)

Except that generally, when am told "next Saturday" - I take that to mean
"the next Saturday" - just one more ambiguity in the english language that
makes it so hard to learn I suppose!

The odd thing about this whole situation it that it seems to have cropped up
just after we "upgraded" to 4.3.9 - prior to that, "next Saturday" worked
just peachy. I wish I knew which version we were running before that - but
that record was not kept.

I guess we are stuck with this, what maybe is a problem with this version,
until the Redhat RPM gets higher than 4.3.9 - since that is what our server
manager uses for updates....

I could always adjust it to be:

date("m/d/Y",strtotime("+ ".(6-date("w"))." days"));

That should always return the next Saturday of the week, and if I am correct
in my thinking, then even on the Saturday, 6-6 = 0 - which would return that
day... Which does, at least for my application of it, work.

I am not sure how the bug that "next" = +2 rather than +1 applys here, maybe
it is just not understanding how exactly the "next whatever" syntax is
applied....

On 1/31/08 12:57 PM, "Richard Lynch" <ceol-i-e.com> wrote:

> Maybe it's just me, but I've never quite figured out what people mean
> when they say "next Saturday"...
>
> Do they mean the next one coming up?
>
> Or do they mean that there's "this Saturday" coming up and "next
> Saturday" the one after that?
>
> And if I can't figure it out, why would you expect PHP to figure it out?
>
> :-)
>
> On Thu, January 31, 2008 10:27 am, Mike Morton wrote:
>> Ya - the other server is 4.4.7
>>
>> However - this does not seem to be the problem necessarily:
>>
>> print date("m/d/Y",strtotime("next saturday"));
>> 02/09/2008
>>
>> print date("m/d/Y",strtotime("next sunday"));
>> 02/10/2008
>>
>> print date("m/d/Y",strtotime("next monday"));
>> 02/11/2008
>>
>> print date("m/d/Y",strtotime("next tuesday"));
>> 02/12/2008
>>
>> print date("m/d/Y",strtotime("next wednesday"));
>> 02/13/2008
>>
>> print date("m/d/Y",strtotime("next thursday"));
>> 02/07/2008
>>
>> So from today to next Thursday, the dates are all 1 week off....?
>>
>> On 1/31/08 11:03 AM, "Tom Chubb" <tomchubbgmail.com> wrote:
>>
>>> On 31/01/2008, Mike Morton <mikewebtraxx.com> wrote:
>>>>
>>>> I have been using:
>>>>
>>>> $nextSaturday= date("m/d/Y",strtotime("next saturday"));
>>>>
>>>> For months long time now with out problems, but in the last two
>>>> days, it
>>>> went kind of funky. It is now returning:
>>>>
>>>> 02/09/2008 instead of the expected 02/02/2008. I have tried the
>>>> same code
>>>> on another server and different version of PHP,and it works ok.
>>>>
>>>> More info:
>>>>
>>>> Shell date: Thu Jan 31 09:44:50 EST 2008
>>>> echo date("Y-m-d g:i A T", time()); = 2008-01-31 10:00 AM EST
>>>> echo date("Y-m-d g:i A T", strtotime("next saturday")); =
>>>> 2008-02-09 12:00
>>>> AM EST
>>>>
>>>> version: 4.3.9 (highest version we can have at the moment)
>>>>
>>>> I could not find this in the known bugs from this version....
>>>>
>>>> So - is this something that is server or version specific?
>>>>
>>>> TIA!
>>>>
>>>> --
>>>> Cheers
>>>>
>>>> Mike Morton
>>>>
>>>> ****************************************************
>>>> *
>>>> * Tel: 905-465-1263
>>>> * Email: mikewebtraxx.com
>>>> *
>>>> ****************************************************
>>>>
>>>> --
>>>> PHP General Mailing List (http://www.php.net/)
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>>
>>> The manual says:
>>> *Warning*
>>>
>>> In PHP versions prior to 4.4.0, *"next"* is incorrectly computed as
>>> +2. A
>>> typical solution to this is to use *"+1"*.
>>>
>>> Dunno if that helps you out? Is the other server > 4.4.0?
>>> http://uk3.php.net/strtotime
>>
>> --
>> Cheers
>>
>> Mike Morton
>>
>> ****************************************************
>> *
>> * Tel: 905-465-1263
>> * Email: mikewebtraxx.com
>> *
>> ****************************************************
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

--
Cheers

Mike Morton

****************************************************
*
* Tel: 905-465-1263
* Email: mikewebtraxx.com
*
****************************************************

attached mail follows:

Mike Morton schreef:
> Good point ;)
>
> Except that generally, when am told "next Saturday" - I take that to mean
> "the next Saturday" - just one more ambiguity in the english language that
> makes it so hard to learn I suppose!
>
> The odd thing about this whole situation it that it seems to have cropped up
> just after we "upgraded" to 4.3.9 - prior to that, "next Saturday" worked
> just peachy. I wish I knew which version we were running before that - but
> that record was not kept.
>
> I guess we are stuck with this, what maybe is a problem with this version,
> until the Redhat RPM gets higher than 4.3.9 - since that is what our server
> manager uses for updates....
>
> I could always adjust it to be:
>
> date("m/d/Y",strtotime("+ ".(6-date("w"))." days"));
>
> That should always return the next Saturday of the week, and if I am correct
> in my thinking, then even on the Saturday, 6-6 = 0 - which would return that
> day... Which does, at least for my application of it, work.

so your actually saying 'find the closest saturday, in the future, from today'.
because if it was saturday, and you said to me "see you next saterday" I'd expect
to see you in 7 days time.

attached mail follows:

On Thu, January 31, 2008 3:29 pm, Mike Morton wrote:
> Except that generally, when am told "next Saturday" - I take that to
> mean
> "the next Saturday" - just one more ambiguity in the english language
> that
> makes it so hard to learn I suppose!

strtotime has always seemed to me like it's bordering on trying to do
"too much"...

I mean, it's practically trying to solve an NLP (Natural Language
Processing) problem, which AI researchers have spent decades and
billions trying to "solve" and they are not exactly getting the
(impossible) job done...

So I never rely on strtotime(), and use something simple like basic
arithmetic to compute days.

It takes out all the ambiguity since Saturday is always day 6 and
adding 7 always ends up on another Saturday.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?

attached mail follows:

Tom Chubb wrote:
> Thanks for all your responses.
> Rich, I guess you're right! Anyway PHP is only a hobby for personal sites,
> so I shouldn't really worry too much but wanted to get a general feel from
> people.
> The only big advantage for the MBP is that it has Firewire 800 which would
> be better for that big hard-drive that I'll need ;)

I don't use a mac myself but a colleague does. He seems to have apache
and PHP installed on the machine but he generally uses the Xampp
package. I don't know if this is the official home page or but but start
here: http://www.apachefriends.org/en/xampp-macosx.html

HTH

Col

attached mail follows:

On 31/01/2008, Colin Guthrie <gmanecolin.guthr.ie> wrote:
>
> Tom Chubb wrote:
> > Thanks for all your responses.
> > Rich, I guess you're right! Anyway PHP is only a hobby for personal
> sites,
> > so I shouldn't really worry too much but wanted to get a general feel
> from
> > people.
> > The only big advantage for the MBP is that it has Firewire 800 which
> would
> > be better for that big hard-drive that I'll need ;)
>
> I don't use a mac myself but a colleague does. He seems to have apache
> and PHP installed on the machine but he generally uses the Xampp
> package. I don't know if this is the official home page or but but start
> here: http://www.apachefriends.org/en/xampp-macosx.html
>
>
> HTH
>
> Col
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

Thanks Colin,
That's what I use on PC so it will probably do me fine on Mac too.

attached mail follows:

> > I don't use a mac myself but a colleague does. He seems to have apache
> > and PHP installed on the machine but he generally uses the Xampp
> > package. I don't know if this is the official home page or but but start
> > here: http://www.apachefriends.org/en/xampp-macosx.html

> Thanks Colin,
> That's what I use on PC so it will probably do me fine on Mac too.

I've been using XAMPP on Windows for a few years, so when I bought a
MBP in December I was happy to find that they have a version for OS X
as well.

The one thing I didn't like about it is that on OS X you have to type
in your password every time you want to start or stop anything. So I
wrote some simple applescripts that I use instead of the included
control panel that handle the authentication for me. If anyone is
interested, just contact me off-list and I'll gladly share these
simple scripts.

Brady

attached mail follows:

On Thu, January 31, 2008 11:44 am, philip wrote:
>
>
> Nathan Nobbe wrote:
>> On Jan 30, 2008 2:47 AM, Per Jessen <percomputer.org> wrote:
>>
>>> Philip, please state what sort of problems you are having. mail()
>>> and
>>> sendmail are both easy to use from php.
>>> And please don't post another 2000 lines of code. No-one is going
>>> to
>>> read them.
>>>
>>
>> amen to that brother! :)
>>
>> -nathan
> Hi guys,
>
> I'm new to both this newsgroups and PHP. I need to get the form
> submission working by Friday (Feb. 1). Any help with sendmailor mail()
> will be appreciated.

I didn't read all 200 lines, but the code you posted seemed to have
SMTP strewn throughout it.

You said you can't use SMTP.

So stop using that code.

Try this instead:
<?php mail('spy_c_xamaicanrogers.com', 'Test', 'Message Body');?>

There, you just used mail() with sendmail.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?

attached mail follows:

On Thu, January 31, 2008 12:50 pm, Richard Heyes wrote:
>> PHP is a server-side page generator. It has NOTHING to do with the
>> browser.
>> The PHP programmer determines the content of the resulting HTML and
>> the
>> browser reacts to THAT. Browsers never see a line of PHP script!
>
> What's your point?

PHP itself cannot, in theory, be the source of the problem.

Therefore, one could claim that it's OT.

Of course, we're talking about the PEAR website, which is used to
acquire/research important components of PHP, so he's wrong, but so it
goes. :-)

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?

attached mail follows:

> -----Original Message-----
> From: Jochem Maas [mailto:jochemiamjochem.com]
> Sent: Thursday, January 31, 2008 8:19 AM
> To: richardhphpguru.org
> Cc: PHP General List
> Subject: Re: [PHP] PEAR website and MSIE 6
>
> Richard Heyes schreef:
> >> firefox not an option?
> >
> > Nope.
> >
> > > or anything else that resembles a proper browser ;-)
> >
> > Strange, IE has been working fine for me for the last eight years...

Yes. http://pear.php.net crashes my IE6 too. This is a problem with the
site, not the browser.

> seriously though - why is FF (or any other browser) not an
> option? your
> a web developer, I would imagine you should be running a
> complete arsenal of
> different browsers as part of the job, no?
> and then there's the question as to why you don't upgrade to
> IE7.

Please stop with the browser wars. They're boring and tired and serve no
purpose. IE6 is fast and launches in 1 second. FF takes many seconds. IE7 is
also a bloated pig and I will be very sad in 15 days when M$ FORCES everyone
to it. IE also has very nice DirectX rendering filters for gradients.

> or maybe rebuild the windows machine in question (hey it wouldn't be
> the first time something
> like this was helped by a clean install right?)

It is NOT the OS. It is the PEAR site itself that is to blame. There is
clearly some code or tag or something that is causing this failure. It
didn't used to be there either. I've gone to the PEAR site many times in the
past. The site isn't even that compex, so I'm curious why the webmaster
couldn't just fix this problem and make everyone happy? Or is the PHP
community so snobbish that they're turning into the Linux community?

I find it so ironic that all the fringe browser people freak out if their
browser isn't supported by some site and demand retribution, yet when the
tables are turned how quick they are to tell 80% of the world to use a 20%
browser...

*sigh*

attached mail follows:

On Thu, January 31, 2008 4:30 pm, Daevid Vincent wrote:
> Please stop with the browser wars. They're boring and tired and serve
> no
> purpose.

> IE6 is fast and launches in 1 second. FF takes many seconds.

Errrr.

Isn't that because IE6 pre-loads everything during the BOOT process,
slowing that down quite a bit?...

> past. The site isn't even that compex, so I'm curious why the
> webmaster
> couldn't just fix this problem and make everyone happy? Or is the PHP
> community so snobbish that they're turning into the Linux community?

Why are you bugging thousands of people on this list about it?

Have you tried to email the PEAR webmaster?

Or filed a bug report on pear.php.net about it?

Or anything more sensible than emailing thousands of PHP-General
subscribers?

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?

attached mail follows:

> -----Original Message-----
> From: Richard Lynch [mailto:ceol-i-e.com]
>
> > IE6 is fast and launches in 1 second. FF takes many seconds.
>
> Isn't that because IE6 pre-loads everything during the BOOT process,
> slowing that down quite a bit?...

I guess. I leave my XP box on all the time, so "boot" is a rare occurance.
Having the browser launch immediately is well worth that tradeoff. I open it
probably 100+ times a day.

> > past. The site isn't even that compex, so I'm curious why the
> > webmaster
> > couldn't just fix this problem and make everyone happy? Or
> is the PHP
> > community so snobbish that they're turning into the Linux community?
>
> Why are you bugging thousands of people on this list about it?
> Have you tried to email the PEAR webmaster?
> Or filed a bug report on pear.php.net about it?
> Or anything more sensible than emailing thousands of PHP-General
> subscribers?

I'm not the O.P. I was just replying to his email that asked if people were
experiencing the same issue. There are 20+ other emails in this thread that
are less relevant than mine actually. Although, I don't think that
expressing a concern over the PEAR official site -- which by definition is
PHP -- is considered "bugging". If YOU were the one that had your entire
browser (tree) close down b/c you innocently went to the PEAR site while
doing your job, which crashed all your other IE windows, I suspect you would
have a different take on this topic.

attached mail follows:

Daevid Vincent schreef:
>
>
>> -----Original Message-----
>> From: Jochem Maas [mailto:jochemiamjochem.com]
>> Sent: Thursday, January 31, 2008 8:19 AM
>> To: richardhphpguru.org
>> Cc: PHP General List
>> Subject: Re: [PHP] PEAR website and MSIE 6
>>
>> Richard Heyes schreef:
>>>> firefox not an option?
>>> Nope.
>>>
>>> > or anything else that resembles a proper browser ;-)
>>>
>>> Strange, IE has been working fine for me for the last eight years...
>
> Yes. http://pear.php.net crashes my IE6 too. This is a problem with the
> site, not the browser.
>
>> seriously though - why is FF (or any other browser) not an
>> option? your
>> a web developer, I would imagine you should be running a
>> complete arsenal of
>> different browsers as part of the job, no?
>> and then there's the question as to why you don't upgrade to
>> IE7.
>
> Please stop with the browser wars.

it's not browser wars - it's pragmatism - thinking aloud about how to
get round the issue - I'm assuming Richard does have access to the PEAR site's
source files or the means to upload them to the PEAR webserver.

They're boring and tired and serve no
> purpose. IE6 is fast and launches in 1 second. FF takes many seconds. IE7 is
> also a bloated pig and I will be very sad in 15 days when M$ FORCES everyone
> to it. IE also has very nice DirectX rendering filters for gradients.
>
>> or maybe rebuild the windows machine in question (hey it wouldn't be
>> the first time something
>> like this was helped by a clean install right?)
>
> It is NOT the OS. It is the PEAR site itself that is to blame. There is
> clearly some code or tag or something that is causing this failure.

let's see now - a webserver outputs some content, it may be invalid. a browser
crashes upon trying to render the content. hmm, sounds to me like the problem is
in the browser, decent software should crash because of shitty input.

granted if the PEAR just didn't render properly or caused 'invalid XML/XHTML/whatever'
message in the browser then yes it would be the site's problem. but until the browser
is capable of saying 'hey this content is junk, I can't use it [because of XYZ]' then
really the first issue is with that browser.

it's same at the server end - if your browser (or you, maliciously) posts freaking/invalid
byte sequences at some script I've got on the server then would you consider it correct
that the server crashed? or would you expect some kind of 'your input sucks' error
message to appear?

> It
> didn't used to be there either. I've gone to the PEAR site many times in the
> past. The site isn't even that compex, so I'm curious why the webmaster
> couldn't just fix this problem and make everyone happy?

we work around bugs and problems all day in the job we do - how is cranking up a
different browser because a site happens not to work with a particular site any different?

if we're really about making everyone happy - how about we tackle something
serious like the whole 'war for oil' business? exactly how fragile is a human mind if
a browser crashing on a particular site is deciding factor in being capable of
experiencing happiness? (not that I'm suggesting this about Richard - Im sure he
was just a little miffed and ping'ed the question out of curiousity more than anything)

> Or is the PHP
> community so snobbish that they're turning into the Linux community?
> I find it so ironic that all the fringe browser people freak out if their
> browser isn't supported by some site and demand retribution, yet when the
> tables are turned how quick they are to tell 80% of the world to use a 20%
> browser...

let's make it sound like they all *chose* IE shall we - a large majority
of that 80% actually think IE *is* the internet, they certainly didn't choose it
because they thought it was the best tool for the job (which it may or may not
be depending or circumstance and/or perspective) - indoctrination and ignorance
do not make good metrics for determining the superiority of a given product ...
keyboard layout being another fine example ... de facto not necessarily equal da bom

>
> *sigh*

indeed

attached mail follows:

Go to windowsupdate. There was an update for IE6 for websites randomly
crashing. I know, because I was affected. Some update broke IE6 and
then you had to update a second time.

Make sure you're all up to date (and restart, sigh) - and it should be good.

On 1/31/08, Richard Heyes <richardhphpguru.org> wrote:
> Anyone have any trouble with this combination? It consistently crashes
> for me.
>
> http://pear.php.net
>
> Thanks.
>
> --
> Richard Heyes
> http://www.websupportsolutions.co.uk
>
> Knowledge Base and Helpdesk software for Â£299pa hosted for you -
> no installation, no maintenance, new features automatic and free
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

attached mail follows:

On Thu, January 31, 2008 1:40 am, Per Jessen wrote:
> Richard Lynch wrote:
>
>> On Mon, January 28, 2008 2:52 pm, Per Jessen wrote:
>>> True again. However, I was commenting on your assertion that
>>> "Process
>>> forking has EVERYTHING to do with thread safety", which I will stay
>>> is
>>> wrong. When you fork another process, you don't need to worry
>>> about
>>> whether your code is thread-safe or not. You don't have to be
>>> reentrant, you could even use self-modifying code if you felt the
>>> urge.
>>
>> Perhaps I mis-remember my C days, but I'm pretty sure it's trivial
>> to
>> write a "fork" program in which both parent and child attempt to
>> utilize the same "global" resource as if they have exclusive access
>> and crash your program.
>
> I think you are mis-remembering, yes. When your fork() call returns,
> you have two separate processes, your child process being an exact
> copy
> of your parent process. (mostly, see "copy-on-write"). The only thing
> they share at this point are open file descriptors which have also
> been
> copied, so they obviously point the the same file(s).

So they could easily corrupt the file by making assumptions about it.

More importantly, if you build and initialize some data structures
before you fork, and if they each assume they have exclusive access to
said data structures, your program ends up not being "thread-safe"

You can call it something else if you like, but it's essentially the
same problem.

>> Sure smells like a thread-safety issue to this naive reader...
>> fork() manages to "do the right thing" for many common resources,
>> but
>> it doesn't handle all of them.
>> If you expect to have two processes running the same lines of codes
>> at
>> once, you need to worry about thread safety just as if there were
>> "real" threads involved.
>
> No you don't. Try this example - think about running the same shell
> script twice, but concurrently. Exactly the same code (the shell
> script interpreter), but not necessarily thread-safe. Try running two
> copies of the mysql cli - same code, but also not thread-safe. You
> can
> fork() any number of processes using the same code without ever
> needing
> to worry about thread safety.

That's funny.

I worry about running two copies of the same PHP script in Apache
child processes and not having them tromp on each other's work...

You may not call this "thread safety" but it smells like the same
animal to me...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?

attached mail follows:

On Jan 30, 2008 7:21 PM, Jochem Maas <jochemiamjochem.com> wrote:
> Greg's my hero of the day - even if he has been banging the Ruby drum on
> the PHP Stage half the night ;-)

PHP is a great language. I don't plan to stop using it anytime soon.

--
Greg Donald
http://destiney.com/

attached mail follows:

Per Jessen schreef:
> Richard Lynch wrote:
>
>>> OK, what is a 'geometry column' and what is a 'spatial index' ?
>> Imagine a single column combining both longitude and latitude.
>>
>> Now imagine an index that "knows" about long/lat, and keeps
>> geographically "close" objects sorted in the index for you.
>>
>> Including "knowing" about the 180 <-> -180 degree wrap-around.
>> (Or 360 === 0 wrap-around in the other geo-system.)
>>
>> So when you ask for "theme parks near Zurich" your DB can answer in
>> milliseconds instead of minutes.
>
> Thanks Richard - I thought Nathan was talking about an abstract concept,
> not something "real".
>
> So, back the Nathans suggestion:
>
>> Back on the mysql side of things, try using geometry columns rather
>> than numerical primary keys, with spatial indexes.. it's a MASSIVE
>> performance upgrade (I've cut 5 second queries down to 0.005 by
>> using geo columns)
>
> Is this worth a try? Have others tried this?

I for one would really like to see a concrete example of this kind of
use of geometry columns and spacial indexes as an alternative to the stand
integer based primary keys.

>
>
> /Per Jessen, ZÃ¼rich
>

attached mail follows:

On Fri, 2008-02-01 at 03:40 +0100, Jochem Maas wrote:

> I for one would really like to see a concrete example of this kind of
> use of geometry columns and spacial indexes as an alternative to the stand
> integer based primary keys.

On one of my local postGIS tables:

CREATE INDEX k1
  ON kanagawa
  USING gist
  (the_geom);

A gist index is a GEOS based spatial index. You will need GEOS to create
one.

When loading spatial data, your geometry column looks like so:

01050000000100000001020000000C00000011ECE564CF7561404A8999CCDABC4140E5C0981ACE75614012901CD641BD4140603C8386BE756140E525611B40BD41405BF216D3BD756140151DC9E53FBD414054DC1A4DBD756140760B997A3FBD414012219BD1BC756140D20823E33EBD41407AB2884EBC7561400F2110243EBD41404571B4D0BB756140CC0C6A213DBD4140F707192ABB7561405DF2A1803CBD4140F0F11CA4BA756140C3D1B7413CBD4140E89CB2ADB97561406F046D233CBD414017D4B7CCA97561406D47AD7F39BD4140

Which is WKB (Well Known Binary) data or WKT (Well Known Text) data. The
gist index simply indexes this as opposed to the regular gid (which you
still use btree indexes on anyways)

--Paul

All Email originating from UWC is covered by disclaimer
http://www.uwc.ac.za/portal/public/portal_services/disclaimer.htm

attached mail follows:

all,

as ive been researching SPL lately ive read several times that spl will
store only the current element of the underlying collection in memory
during iteration. articles that mention this will say that using these
iterators should afford savings when traversing large collections. well
having found nothing empirical i decided to run some tests myself.
and for the hell of it, i also decided to throw the array-by-reference
construct in there (thats the name im giving to the syntax which lets
you alter the array youre iterating over from within the array). mainly
because ive heard people say it will save memory. however, based
upon some things ive read, ive been skeptical of that info.
so here is a quick little report i whipped up, which has the script i used
for the test, and the results in a graphical format so you can get a quick
feel for them.
http://nathan.moxune.com/arrayVsArrayIteratorReport.php

at this point i must retract some of the statements i made during the
conversation about ruby yesterday. it turns out, spl iteration is not
twice as fast as standard array iteration, in fact it quite a bit slower!
also, it takes up more memory, and lastly, whoever said that using the
array-by-reference syntax saves memory is dead wrong ;)

-nathan

attached mail follows:

The next major release of the Chisimba PHP5 framework is now available.

Major enhancements included in this release are:

- Remote downloads of modules through web interface
- Upgrades of modules via package server in modulecatalogue
- Skin downloads via remote package server
- Updates to modules and core framework now taken care of via remote
- Better use of caching mechanisms (fixed a lengthy file compile for
APC in engine class)
- Major bugfixes to the e-Learning modules and context
- Major improvements on usability for context
- Additional skins to play around with

and, of course, new modules to add onto your installation!

Please take a look, download it and give it a test drive!

Chisimba, for those that don't know it already, is a PHP5 framework made
in Africa, for Africa. It is a collaboration between around 16 African
Universities, as well as around 35 active developers from around the
continent.

It can be downloaded from AVOIR at:

http://cvs2.uwc.ac.za/chisimba_releases/chisimba_framework_2-0-0-rc1.tgz

http://cvs2.uwc.ac.za/chisimba_releases/chisimba_framework_2-0-0-rc1.zip

and the documentation wiki can be found at:

http://avoir.uwc.ac.za/avoir/index.php?module=wiki

The Chisimba Book will be made available with Chisimba-2.0.0 (i.e. after
the RC's have passed the test).

There are server setup instructions, as well as installation
walkthroughs available linking from the main AVOIR site:

http://avoir.uwc.ac.za/avoir/index.php?module=cms&action=page&id=gen12Srv48Nme23_207

This is a major upgrade to previous Chisimba installations, so if you
are already using Chisimba, please consider upgrading immediately!

For those interested in developing a module, or just getting some
additional info please take a look at:

http://avoir.uwc.ac.za/avoir/index.php?module=cms&action=page&id=gen12Srv48Nme23_208

Please report any issues on the mailing list(s) or in our bug tracking system:

http://mailman.uwc.ac.za/mailman/listinfo/nextgen-users
http://avoir.uwc.ac.za/mantis/

--
------------------------------------------------------------.
| Chisimba PHP5 Framework - http://avoir.uwc.ac.za |
:------------------------------------------------------------:

All Email originating from UWC is covered by disclaimer
http://www.uwc.ac.za/portal/public/portal_services/disclaimer.htm

attached mail follows:

Hello,

Has anyone tried to use this function? Does php actually support mysql
embedded server or is this just a stub for future use? I'm trying to convert
a mysql-based web app to a desktop app and rather than refactor everything
to use sqlite, It would be interesting if I could use mysql embedded server.

Thanks!

--
-- Luke Kyohere
-- /dev/null

attached mail follows:

Kyohere Luke wrote:

> Has anyone tried to use this function? Does php actually support mysql
> embedded server or is this just a stub for future use? I'm trying to
> convert a mysql-based web app to a desktop app and rather than
> refactor everything to use sqlite, It would be interesting if I could
> use mysql embedded server.

Alternatively, you could just run mysql locally on your desktop.

/Per Jessen, ZÃ¼rich

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]