Re: [PHP-DEV] Is this a bug?

[Chris Shiflett]

--- Tony Bibbs <[EMAIL PROTECTED]> wrote:
> Are there instances you all can think of where doing a header('location: 
> $url'); causes a loss of all session data?

This is most likely not a bug. You can (hopefully) find more people to help
with this type of question on [EMAIL PROTECTED]

Good luck.

Chris

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Bug #17868: Multiple Includes

[Chris Shiflett]

--- Maxim Maletsky <[EMAIL PROTECTED]> wrote:
> 
> "Michael D. Petersen" <[EMAIL PROTECTED]> wrote... :
> 
> > I have been following PHP Bug #17868 for some time
> > now (since upgrading to Red Hat 8.0 and Apache 2.0)
> > with quite a bit of interest.  This is the bug 
> > where multiple include statements don't work and
> > only the first one gets parsed by PHP.
> 
> Yes, only the first one gets parsed by all the
> subsequent get executed. This speeds the process up
> - what's the problem?

I think you misinterpreted the bug (unless I am instead),
but Rasmus already responded that the problem lies with
Apache 2's filters and that the Apache guys are well aware
of the problems with that API.

Chris

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Digest Authentication Extension

[Chris Shiflett]

Is anyone working on an extension for digest
authentication? If not, I think I will write one.

While I am on the topic, what about basic authentication?
Yes, I know people get by with header() and doing it
manually, but I could just make the extension cover both
basic and digest, where the users can choose between the
two.

Chris

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Cookie Session Problem

[Chris Shiflett]

--- Michael Conroy <[EMAIL PROTECTED]> wrote:
> I'm using cookies for a php session.
> 
> The problem i'm having is that the session id is showing
> up in the url when a user moves to the next page in the
> site, but then after that it stop showing up in the url
> (the way it should be). I don't want the session id
> (periodically) showing up in the url this causes me
> problems on certain things.

It is session.use_trans_sid. Locate it in your php.ini and
turn it off like this:

session.use_trans_sid = 0

Chris

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Capturing headers with output buffering?

[Chris Shiflett]

You can probably learn a lot by example. There is a pretty complete
HTTP server written in PHP available here:

http://nanoweb.si.kz/

Chris

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error reporting for PHP5

[Chris Shiflett]

I quite like Maxim's ideas myself.

+1

--- Maxim Maletsky <[EMAIL PROTECTED]> wrote:

> I will start laying out some my thoughts to hopefully get a
> discussion towards working on the complete error reporting logic.
> I had an extensive experience implementing custom errors, so
> approve or disapprove my ideas.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Chris Shiflett]

--- John Coggeshall <[EMAIL PROTECTED]> wrote:
> See, the problem that I'm seeing here is that I don't believe PHP
> is reponsible for setting the error code returned by PHP.. For
> instance, a 404 error isn't handle by PHP at all. Likewise, I don't
> think PHP can say "turn this into a 500 error" to Apache.

How do you think PHP is able to change the HTTP response code when
someone uses a header("Location: ...") in their code? :-)

I also believe that header("HTTP/1.1 500 ...") will do the trick, and
there is also the revamped Apache hooks stuff that is being worked on
that should give even more control to developers who choose to use
it.

Chris

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS Account Request: mrioux

[Chris Shiflett]

Out of curiosity - why is this?

I assume it is because such an extension would somehow be required to be 
covered under the GPL as well, but I don't understand that. Shouldn't it 
be possible for the PHP extension's code to be licensed any license and 
simply use a GPL library? The extension's code would be copyrighted by 
the author, correct? So, why can't the author decide what terms his/her 
code is licensed under?

Just curious - I've heard this before and have never understood.

Chris

Rasmus Lerdorf wrote:

libsmbclient is gpl'ed, correct?  We cannot accept extensions that are
written specifically against a single GPL'ed library.  Sorry.

-Rasmus




--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :)

[Chris Shiflett]

I vote we leave it on.

Chris

Zeev Suraski wrote:


Thank you for the detailed explanation, I'm sure everybody understands 
it now.

Let's go for the voting phase.  I vote we keep PHP-CLI with 
implicit_flush on by default.  You vote against.

Can we get some other votes now (not opinions, everything was already 
said a dozen times, just votes to get this over with). 



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

[Chris Shiflett]

While I think it is a bit unintuitive to have $_FILES separate like it 
is (rather than a part of $_POST, for example), I think it would be much 
worse to also separate it from $_REQUEST. After all, as Sterling pointed 
out, it is part of the request.

Chris

Derick Rethans wrote:

>On Wed, 16 Oct 2002, Melvyn Sopacua wrote:
>
>>At 23:13 15-10-2002, Yasuo Ohgaki wrote:
>>
>>>Another option.
>>>
>>>How about remove $_FILES contents from $_REQUEST?
>>>It seems it has less impact.
>>>  
>>>
>>I don't think Zeev and Derick will be able to go on any trips for a while
>>then :-)
>>
>>First 'force' people to use superglobals, then say "ehm - yeah, but ehm
>>uploaded files are not userdata, because they are not in $_REQUEST".
>>
>>
>
>I would have no problem with leaving out $_FILES from $_REQUEST...
>
>Derick
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

[Chris Shiflett]

Thanks, I see your point now.

I like the solution 2, even though it is a bit ugly.

Sterling Hughes wrote:

>On Wed, 2002-10-16 at 05:35, Chris Shiflett wrote:
>  
>
>>Is the thought here that no one will be depending on the weird format of 
>>the $_REQUEST array as mentioned in the bug report? If we're worried 
>>about BC, I don't see why we should favor one group of people (those 
>>using $_FILES) over another (those using $_REQUEST), unless I'm missing 
>>something ...
>>
>>
>>
>Simply because you really couldn't use $_REQUEST to access the files
>array in the past, at least not without risking some dangerous
>things/messed up results.  The idea is while we can't normalize the
>source, we _must_ normalize it when it seeps into other parts of php.
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

[Chris Shiflett]

Right. I was just wondering if there was a reason why the $_POST array 
wasn't originally created like Sterling suggested for $_FILES and 
$_REQUEST in his solution 1:

$_FILES['toto']['c']['type'] and $_REQUEST['toto']['c']['type']

Meaning, I'm not clear why $_FILES is necessary, since the same approach 
can be taken for files in the $_POST array, mixing them with other types 
just like $_REQUEST does (the suggested way above, anyway).

Also, solution 2 mentioned was this:

 > $_REQUEST['toto']['c']['type']
 >
 > and
 >
 > $_FILES['toto']['type']['c']
 >
 > which is ugly and just not right, but it maintains backwards
 > compatibility with the $_FILES array.

Is the thought here that no one will be depending on the weird format of 
the $_REQUEST array as mentioned in the bug report? If we're worried 
about BC, I don't see why we should favor one group of people (those 
using $_FILES) over another (those using $_REQUEST), unless I'm missing 
something ...

Chris

Rasmus Lerdorf wrote:

>Because there is more data associated with a file upload than just a
>single piece.
>
>On Tue, 15 Oct 2002, Chris Shiflett wrote:
>  
>
>>Out of curiosity, why are files treated differently than all other form
>>variables submitted via POST?
>>
>>We don't have $_TEXT, $_RADIO, etc.
>>
>>Maybe there is a good reason, but it seems counter-intuitive to me.
>>
>>Chris
>>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

[Chris Shiflett]

Out of curiosity, why are files treated differently than all other form 
variables submitted via POST?

We don't have $_TEXT, $_RADIO, etc.

Maybe there is a good reason, but it seems counter-intuitive to me.

Chris

Sterling Hughes wrote:

>On Wed, 2002-10-16 at 04:45, Jani Taskinen wrote:
>  
>
>>On Wed, 16 Oct 2002, Yasuo Ohgaki wrote:
>>
>>
>>>Another option.
>>>
>>>How about remove $_FILES contents from $_REQUEST?
>>>It seems it has less impact.
>>>  
>>>
>>+1 for this option. There's really no need it for to
>>be in $_REQUEST..
>>  
>>
>>
>
>except that its data coming from the "request" ? :)
>
>-Sterling
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

[Chris Shiflett]

I'm -1 on removing short tags, whether now or for PHP5.

I use a Web host that allows short tags, and I can do this to add my XML 
header to be XHTML compliant:

\n"; ?>

Yes, perhaps it is slightly annoying to not just be able to write the 
 without it being interpreted by PHP (I think that was the 
original argument, right?). However, I cannot imagine how someone can 
truly justify causing so much pain for so many PHP users for something 
semantic like this. Look at the hardship the register_globals change 
made, and that was:

1. Just a default setting that can be changed back rather than something 
we removed completely.
2. Something that had a significant purpose; it helps inexperienced 
developers avoid some common security mistakes.

Again, -1 from me.

Chris


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] variables

[Chris Shiflett]

You should direct these types of problems to [EMAIL PROTECTED] 
You will find many people eager to help.

As for your problem try this:

echo $_GET["action"];

Happy hacking.

Chris

Sean wrote:

>I have inherited the support of a PHP website that doesn't seem to be
>recognizing the data from the URL. Suppose the URL is index.php?action=run.
>I have the following code that I expect to display "The selected action is
>run":
>
>print "The selected action is ";
>print $action;
>
>What I get is the "The Selection action is " text, but $action is always
>empty.
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Seeking Comments - Regarding header()

[Chris Shiflett]

I have a few sites where I deliberately violate the HTTP spec in this 
way to get around a bug in IE (I know, shame on me). I've been using 
relative URLs in a "Location" header for years with no crashes that I 
know of.

There must be something unique in your configuration. Have you mentioned 
this to the Apache guys?

Chris

Mike Hall wrote:

>>On Fri, Jun 21, 2002 at 10:48:33AM +0100, Mike Hall wrote :
>>
>>
>>>You could hardly describe it as a bug if Apache crashes because you're
>>>sending Headers that violate the spec, surely?
>>>  
>>>
>>Hmm  ... I'm not sure. I don't think apache should crash. but
>>then how can you be sure it's apache who crashes and not php?
>>If it's an apache crash it maybe can be missused too (though
>>not remotely).
>>
>>
>
>Well, if you send relative URLs in a Location: header, it causes
>intermittent sig11's in Apache. Don't know if that is mod_php causing them,
>or apache. But it does happen. I had that problem on GG.COM .. took me weeks
>to track it down to relative location headers.
>
>--Mike
>
>
>
>  
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Seeking Comments - Regarding header()

[Chris Shiflett]

A topic was brought up on PHP general that the "Location" header should 
change the HTTP response code to 304 rather than 302. Rasmus suggested 
that this person submit a patch, and that it would be considered.

I decided to look into this a bit more.

A 302 response code seems more appropriate as a "default" response code 
to use when a user uses the "Location" header in some PHP code. However, 
even though it is commonly used in code handling a POST request (to 
avoid a reload=repost situation), the specification says that a response 
of 302 to any method other than GET or HEAD must *not* automatically 
redirect the user. Most browsers that I know of deliberately violate 
this, as I know several open source projects that make use of the 
redirect behavior after a POST.

After reviewing the other 300-level responses, it seems that the 
definition and the implementations are rarely in synchronization. Thus, 
what would others think of adding a way for PHP developers to specify 
their own HTTP response code? I don't think this is currently possible, 
though if it is, you can ignore everything I've said. :)

This could be allowed as an additional (optional) parameter of the 
header() function, or it could be a separate function. Rather than try 
to enforce the HTTP specification through the PHP engine itself (such as 
making sure the required headers of certain response codes are included 
in the response), the responsibility of generating a correct and proper 
response would be the developer's.

Yes, this could have the unfortunate side-effect of poor developers 
carelessly using this feature and rendering parts of their applications 
useless on some browsers, but it would allow advanced developers even 
more control over the HTTP response. After all, that response is what 
developers are most interested in, so why not give them all the control 
over it that we can?

Just an idea. I would, of course, volunteer my time to the development 
of this if it sounds like a good idea.

Chris


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] problem with post data

[Chris Shiflett]

The reason for this is most likely that your PHP configuration is not 
setup to create global variables for data contained in a POST.

You'll probably find more help on the [EMAIL PROTECTED] mailing 
list. This list is for the development of PHP only.

Chris

rang pheng wrote:

>Hi. I'm Rang.
>
>Now I try develop with php.
>
>But when I pass data from the Form why I can not get it.
>
>I code it follow :
>
>form.html
>
>
>
> 
>
>
>
> 
>
>
>
>
>
>form.php
>
>
>echo "data pass from form is :$txtname";
>
>?>
>
>Yes, when I try to submit the form the error is :
>
>Notice: Undefined variable: NAME in d:\inetpub\wwwroot\php\testform\formtest.php on 
>line 2
>
>
>How it is wrong ! It wrong my configuration.
>
>Please help me to correct this problem.
>
>Thanks in advance.
>
>Bye bye.
>
>
>
>-
>Do You Yahoo!?
>Sign-up for Video Highlights of 2002 FIFA World Cup
>  
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PECL != Siberia

[Chris Shiflett]

Dan Allen wrote:

>Call me arrogant, but just use Linux for crying out loud.
>
OK. You're being arrogant.

>Doesn't this debate make it clear that windows just sux when it
>comes to doing anything remotely complicated.  IMHO.  I had to say
>it.  But if you feel that you have all the time in the world,
>support crappy OSes.
>
Promoting Linux is fine, and many on this list will agree that it's a 
superior operating system. Time spent supporting one of the most popular 
operating systems is *not*, however, a waste of time.

The fact that PHP runs on so many platforms with so many other products 
(such as databases) is likely the major reason why it is quickly 
becoming *the* dominant Web scripting language.

Your argument goes against everything the free software movement stands for.

Chris


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] errno-13 Persmission Denied

[Chris Shiflett]

A directory has to have execute privileges for you to
be able to do anything within it. A mode of 666 does
not have execute privileges for anyone, while 777
does.

Chris

--- Anil Garg <[EMAIL PROTECTED]> wrote:
> Hi,
> 
>  I am trying to upload a file in to a
> directory(which has mode 666)
> It gives the followring error:
> 
> Warning: stats failed for
> /netvcr/www/archive/data1.cab (errno=13 -
> Permission denied) in
> /z/mercury/www/data/content/admin/do_upload.php on
> line 16
> ---
> but it works fine if the directory has a mode of
> 777.
> 
> Can anyone help me by telling how i can i upload
> this OR suggest some other
> way to keep my documents more secure??
> 
> Any pointers are appreciated.
> anil garg
> 
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 
> 


__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)

[Chris Shiflett]

I agree. Though I know we want to stay well away from bundling anything 
unnecessary with a "base" PHP installation, more sophisticated session 
support seems well warranted, possibly even enough to extend the 
capabilities of PHP's current built-in session management *and* include 
msession in some way.

Chris

Steve Meyers wrote:

>Well, you didn't try it with MySQL, which is significantly faster than 
>Oracle and Postgres for most stuff.  In any case, I agree that msession is 
>probably a better solution -- I just think that having built-in MySQL 
>session support would be a good thing for PHP.
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)

[Chris Shiflett]

Daniel Lorch wrote:

>I'd like to make a suggestion here: What do you think of splitting up
>the current PHP Manual into three major parts:
>
>  1. Developing in PHP ("for PHP users")
>  2. Extending PHP
>  3. PHP for System Administrators
>
>Part 3 would cover all topics interesting only to a system
>administrator, such as installing PHP, security issues (open_basedir,
>safe_mode, alternatives such as fastcgi, tweaking the configuration on
>a vhost basis, ..), installing PHP on web farms etc..
>
>These topics usually don't interest the average PHP developer - why
>keep it in the same manual, then?
>
>What do you think about this?
>
+1 - Maybe even consider adding to part 2 some documentation on 
developing PHP itself. Right now, one must read the few files on the 
Zend API, some coding standards, subscribe to this list, and use the 
force (read the source) - not that this approach is all bad.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)

[Chris Shiflett]

I probably don't have the background on msession that I need to make an 
intelligent comment, but here is an opinion of mine that is relatively 
on-topic.

The regular session implementation in PHP is extremely flexible, right? 
Sure, since you can write your own functions to do things such as store 
session data in a database, etc. However, there is *nothing* to help the 
average developer implement a professional-grade state management system 
out of the box. At least, not that I'm aware of. Everyone will happily 
explain how sessions in PHP work and then follow with a recommendation 
to *not* use sessions as they work out of the box, because data is 
stored in /tmp, etc.

Take a competing product, such as ColdFusion, and configuring a database 
to use to maintain session data is a simple option. The functions that 
power the database session activity are part of the engine itself, and 
they're very quick and efficient. Every developer doesn't have to 
reinvent that wheel. Running a cluster of servers is cake.

It sounds like msession has more of an enterprise perspective, and it 
might just have a few benefits worth considering. Session management is 
a huge deal in enterprise-level Web development, and I don't have to 
tell you guys how many developers have no idea what they're doing. If we 
have code that helps people do things the right way, I think it would go 
a long way in helping PHP. Why has no one suggested that features in 
msession be incorporated into the standard session module? I sure would 
hate to think that personality conflicts are getting in the way here.

On a different topic, has there ever been a serious discussion about 
embedding commands in the PHP engine that allow for PHP administration? 
For example, an "administrator" PHP application would come bundled with 
PHP, and when dropped into document root, it would allow for Web-based 
administration of PHP. There are ways to secure this type of a system 
such that other PHP applications couldn't just use the same functions to 
perform their own rogue administration. This system could also allow us 
to provide a database abstraction layer to PHP without users have to 
write their own or copy someone else's in the business logic itself. We 
could leave that type of code in the engine and probably make it much 
faster.

Anyway, some random thoughts from a listener.

Chris

[EMAIL PROTECTED] wrote:

>I kind of went off in a huff yesterday with the whole PECL/pear issue with  
>msession, it's over and lets move on. I did, however, want to explain *why*  
>I think msession should be in the main code. 
> 
>In *big* websites, you need multiple web servers serving copies of the same  
>data in a load balanced environment. The PHP session code, in its native  
>state, can not manage this efficiently. You need some sort of external session  
>management system.  
> 
>Putting aside msession or SRM for the moment, the capability of linking  
>multiple PHP web servers is vital. As one scans the PHP site, it is not  
>immediately obvious how this is done, or that it can be done at all. You have  
>to do a bit of digging to figure out how to do it. 
> 
>I have worked as a software developer for almost 20 years now, and it has  
>become obvious to me that people in charge of making technology decisions are  
>not as technically savvy as we would like or is often assumed. They NEED to be  
>spoon-fed. If they have to look for something, they will probably assume it  
>does not exist and opt for the solutions that are marketed at them. 
> 
>Obviously I think msession is pretty good, but SRM works too.  Regardless of  
>which, or even either, PHP needs to make an ?enterprise? statement.  
>Marginalizing this capability IMHO is not the right direction, I think there  
>should, in fact, be a stronger push for this sort of capability to be built in  
>by default. 
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Safe Mode

[Chris Shiflett]

Zeev Suraski wrote:

> At 20:17 11/05/2002, Rasmus Lerdorf wrote:
>
>> > Ideally every ISP would use it and each virtual host would have such a
>> > directory. In reality I've set to see a SINGLE ISP that has used 
>> that option.
>> > In fact I didn't know about it myself until you told me about on IRC.
>>
>> Well, it is well documented.  The ignorance and stupidity of many 
>> ISP's is
>> just a fact of life.  I am a firm believer in Darwinism amongst ISP's 
>> and
>> figure the really stupid ones will eventually die off.  I am not 
>> going to
>> go out an actively shoot them though, because that might be illegal.
>
>
> Do we have any sort of an PHP-ISP-HOWTO?  If not, are there any 
> volunteers to write one?  I think it may be a good idea, because 
> Darwinism goes both ways - if too many people get bitten by PHP, 
> they'll switch to other solutions.
>
> Zeev

I gladly volunteer to help with this effort.

Chris




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Bug #17128 Updated: lstat (mis)behaves exactlylike stat

[Chris Shiflett]

Yasuo Ohgaki wrote:

> Andrew Rice wrote:
>
>>  ID:   17128
>>  Updated by:   [EMAIL PROTECTED]
>>  Reported By:  [EMAIL PROTECTED]
>>  Status:   Open
>>  Bug Type: Filesystem function related
>>  Operating System: Debian GNU/Linux 2.2
>>  PHP Version:  4.2.0
>>  New Comment:
>>
>> is_link is also broken
>>
>>
>> Previous Comments:
>> 
>>
>> [2002-05-09 16:03:08] [EMAIL PROTECTED]
>>
>> lstat tracks through symbolic link and returns the permission mode of
>> the actual file, rather than the link itself.
>> fileperms also seems to be affected.
>>
>> 
>>
>
> We have problems with file system functions consistently.
> One of the reason is a function does too many things.
> When someone fixes a bug, then introduces new bug :(
>
> It's better to be split into sevral managable parts at least,
> since current source is not managable obviously...
>
> Any comments?
>
> -- 
> Yasuo Ohgaki


Sounds like the Unix philosophy to me. Do one thing and do it well.

However, you will probably have to give more details about what you're 
planning to do before anyone will give much support.

+1 for the general idea from me.

Chris


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV]

[Chris Shiflett]

> Perhaps if it were a computer making these assumptions, yes. But anyone
> with half a brain can see that  is much easer to
> understand for someone with no programming experience, than:
> .

Agreed, Sterling. I can't understand why this is so difficult to realize. 
Theo, are you just trying to impress people by saying how easy the cryptic 
syntax is? If so, it's not working.

> I, and others, would argue that ' ' Thanks for the tip, we didn't realize that.

Well, Sterling, the sarcasm might have ben a bit harsh, but I must admit I 
laughed out loud when I read it. :)

It's too bad really that http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] cvs: ext/baby

[Chris Shiflett]

Woo hoo! Congratulations, Rasmus!

Chris

On Wed, 6 Mar 2002, Rasmus Lerdorf wrote:

> @@ -1,2 +1,6 @@
>  Christine Lerdorf
>  Rasmus Lerdorf
> +Buster (working name only) Lerdorf
> +Born 13:26 PDT Wednesday March 6, 2002
> +Weight: 9.0 pounds
> +Length: 19.25 inches
> 
> 
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] FW: Response.redirect!!!

[Chris Shiflett]

Maybe suggest to our friend that he learn some HTTP. It sounds to me like 
he just wants to do a protocol-level redirect.

Of course, it's a bit difficult to discern anything useful, but that's 
what I got out of it. Of course, PHP already allows this, but it's not 
disguised as a proprietary function.

Chris

On Fri, 22 Feb 2002, Rodent of Unusual Size wrote:

> Sent to the Apache contact address.  I told him I was forwarding
> it, but that he might not get a reply if his message was considered
> too rude.. :-)
> 
> - Forwarded message from Tomas Marklund <[EMAIL PROTECTED]> -
> 
> From: "Tomas Marklund" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Subject: Response.redirect!!!
> Date: Thu, 21 Feb 2002 15:19:53 +0100
> Thread-Topic: Response.redirect!!!
> Thread-Index: AcG64tQ8eiZG89jOSfOaHiq6BNlW2Q==
> 
> Why can't you program the most wanting function of them all, and the
> only thing that is better in ASP than PHP!!
> THE Response.redirect command!?++
> 
> The header is to difficult to use!!!
> 
> /Tomas Marklund
> 
> - End forwarded message -
> 
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Override session id creation and cookie creation?

[Chris Shiflett]

Wow, that's nasty. :)

The cookie to get picked up will be the first one encountered as the 
Cookie header's value is parsed from left to right.

Are these session cookies or persistent? I'm quite confused as to how the 
browser is keeping two identical cookies. I'll try to look more into the 
protocol.

Chris

On Mon, 18 Feb 2002 [EMAIL PROTECTED] wrote:

> > 
> > Try running some tests on this where you have the page you're talking 
> > about and an additional page that dumps all environment variables you
> > can  think of. Or, if you have a way to snoop the HTTP request (2nd
> > request)  from your browser, that would be even better.
> > 
> > Your problem *might* be that you have two cookies named PHPSESSID, but
> > one  is lowercase and one is upper.
> > 
> > Just a thought.
> .php
> 
> GET http://test.test.de/test/ms-test.php HTTP/1.1
> Host: test.test.de
> Cookie: PHPSESSID=d9casjny42bdn67j4lbn7ycmbrqi3x6i; 
> PHPSESSID=21955e976244c0635a0c9ad6a71e92a9
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, 
> application/vnd.ms-powerpoint, application/vnd.ms-excel, 
> application/msword, */*
> Accept-Language: de
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
> Proxy-Connection: Keep-Alive
> Accept-Encoding: gzip, deflate
> 
> 
> 
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Override session id creation and cookie creation?

[Chris Shiflett]

Try running some tests on this where you have the page you're talking 
about and an additional page that dumps all environment variables you can 
think of. Or, if you have a way to snoop the HTTP request (2nd request) 
from your browser, that would be even better.

Your problem *might* be that you have two cookies named PHPSESSID, but one 
is lowercase and one is upper.

Just a thought.

Chris

On Mon, 18 Feb 2002 [EMAIL PROTECTED] wrote:

> In my module, msession, I have routines that guarentee that a session id 
> is unique within a cluster of web servers.
> 
> The problem I have is that session creates and sets the session cookie 
> without some mechanism to allow me to replace the session id string, prior 
> to the session code setting the cookie.
> 
> In some test code I have, I set the PHPSESSID cookie with my value, and 
> replace the internal value used, but oddly enough both values exist in the 
> browser, and depending on any set of random events, it is not predictable 
> which PHPSESSID value gets used.
> 
> Any hints? Tips?
> 
> 
> 
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #15415: [VOTE] case sensitive function/class namesfor PHP5

[Chris Shiflett]

Actually he (read: I) didn't read the whole email; I've developed this 
habit of ignoring all but the "content" section of emails sent to this 
list.

Sorry :)

On 6 Feb 2002, Lars Torben Wilson wrote:

> On Wed, 2002-02-06 at 17:34, Chris Shiflett wrote:
> > NO
> 
> I think he meant to vote using the voting form in the bug 
> database. ;)
> 
> 
> Torben
> 
> > On 7 Feb 2002 [EMAIL PROTECTED] wrote:
> > 
> > > From: [EMAIL PROTECTED]
> > > Operating system: ANY
> > > PHP version:  4.1.1
> > > PHP Bug Type: Feature/Change Request
> > > Bug description:  [VOTE] case sensitive function/class names for PHP5
> > > 
> > > Please vote "YES" if you *LIKE* case sensitive function/class/constant
> > > names under PHP5.
> > > 
> > > Please vote "NO" if you *DO NOT LIKE* case sensitive
> > > function/class/constant names under PHP5.
> > > 
> > > Thank you.
> > > 
> > > 
> > > PS: I'm creating this report(vote) as a result of Zend Engine 2 and
> > > php-dev list discussion. Don't cheat, please :)
> > > 
> > > 
> > > 
> > 
> > 
> > -- 
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #15415: [VOTE] case sensitive function/class namesfor PHP5

[Chris Shiflett]

NO

On 7 Feb 2002 [EMAIL PROTECTED] wrote:

> From: [EMAIL PROTECTED]
> Operating system: ANY
> PHP version:  4.1.1
> PHP Bug Type: Feature/Change Request
> Bug description:  [VOTE] case sensitive function/class names for PHP5
> 
> Please vote "YES" if you *LIKE* case sensitive function/class/constant
> names under PHP5.
> 
> Please vote "NO" if you *DO NOT LIKE* case sensitive
> function/class/constant names under PHP5.
> 
> Thank you.
> 
> 
> PS: I'm creating this report(vote) as a result of Zend Engine 2 and
> php-dev list discussion. Don't cheat, please :)
> 
> 
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: shiflett

[Chris Shiflett]

Initially, I want a CVS account in order to be able to close bugs. Perhaps I can save 
other developers valuable time by eliminating bogus bugs or better explaining the 
problem for legitimate ones.

I eventually want to contribute regularly to PHP itself, initially dealing with all 
things session related.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Developer Seeking To Help

[Chris Shiflett]

On Sun, 3 Feb 2002, Manuel Lemos wrote:
Manuel,

Thank you for the suggestion. If you would be so kind, I have a few 
questions.

1) How can I change the status of a bug? For example, I was looking 
through session bugs (since that's most likely where I could contribute 
the easiest) and read a bug #14227. This bug is bogus and is the result of 
the submitter not understanding HTTP and the Set-Cookie header enough. I 
would love to be able to act as a mediater of sorts, so that the bogus 
bugs can be filtered to save developers some time. I can even give 
elaborate explanations in the beginning to make sure people know why it's 
bogus. :)

2) If a bug is legitimate, and I know how to fix it, how do I go about 
doing this? Must I receive permission for a CVS account? How does one gain 
the trust to be able to commit changes?

3) How do I know if someone is working on a bug? If it is "open" status, 
can I safely assume it's not been investigated by a member of the PHP 
development team?

Thanks for the information.

Chris


> Hello,
> 
> Chris Shiflett wrote:
> > I know there are also mundane tasks that need accomplishing, and I
> > would be more than willing to help with some of these as well.
> 
> Suggestion: have a go at the bug database, talk to the QA team and see
> what is most urgent to be fixed. That would be of a great help.
> 
> Regards,
> Manuel Lemos
> 
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Developer Seeking To Help

[Chris Shiflett]

Hello,

I have recently subscribed to this developer's list with the hopes of 
finding more information about how to contribute to the PHP project.

At the risk of having this sound too much like a job application, I 
wanted to say just a few things about myself and my interests, so that 
hopefully someone will identify me as being potential assistance in some 
area of development that they are associated with.

I value open source software over proprietary, modesty over pride, and 
creativity over intelligence. I am an expert in the HTTP protocol and an 
experienced web developer. I began my web development with CGIs in C, 
moved to Perl, and now primarily create in ColdFusion and PHP. I currently 
work for the USPS as a Technical Program Manager, which basically means 
that I lead a group of developers and act as a liason between the 
programmers and the business management. With this position, I have been 
"enlightened" with the business perspective in regards to software.

My primary interests in PHP development would be aiding with the evolution 
and improvement of the wonderful new session management capabilities in 
PHP. I know Sascha and Andrei probably don't need any help, but I would 
love to give it if they do. Most of my ideas in this area revolve around 
making it easier for inexperienced developers to be able to implement 
secure session management into their applications without removing any 
flexibility for the experienced ones. I'm sure many of my ideas are not 
original, but I think that some just might be.

Another major area of interest would be to add to the native PHP 
functions. Specifically with regards to date/time functions, many common 
tasks in dealing with dates and times must be done with several lines of 
PHP where a native function could improve performance and ease 
development, especially for inexperienced developers (see a trend? :)).

I know there are also mundane tasks that need accomplishing, and I 
would be more than willing to help with some of these as well.

Best regards.

Chris Shiflett
[EMAIL PROTECTED]


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php