Stefan Esser writes here:
http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html
that allow_url_include (and allow_url_fopen) can be easily worked around
- i.e. extrenally-supplied code executed on server - by using php: and
data: URLs. I think if we want allow_url_inclu
[EMAIL PROTECTED] wrote:
> I'm using the following code:
>
> header("Status: 301 Moved Permanently");
> header("Location: mynewurl");
> exit();
Never ever use a Status header.
Either set the third param to header() to the intended response status code
or use a "HTTP/1.1 301" header string. See
Can you please answer my request? ;-)
""Sascha Holtbrügge"" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
> Translating the documentation into german language
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
To all,
Congratulations on the release of 5.2 folks.
Once again, I wish to express my sincere gratitude to the PHP team, dev and
docs,
for their hard work, dedication and perseverance in maintaining and
advancing this
magnificent language. Not to mention your incredible patience. :)
You continu
Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP.
This is common in PHP and you consider this good practice? Interesting,
wasn't what I would have expected...
Now given Liskov
rules you can as well add default parameter
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application futureproof.
I'm still wary of this approach because it puts the burden on 99% of the
code to be written (applications) instead of a small, controllable
subset (core and libraries).
When developing a distribute
Hello Christian,
Saturday, November 4, 2006, 5:13:32 PM, you wrote:
> Marcus Boerger wrote:
>> Liskov applies to static methods as soon as calls via objects are common
>> which is true for PHP.
> This is common in PHP and you consider this good practice? Interesting,
> wasn't what I would ha
On 4-Nov-06, at 11:18 AM, Christian Schneider wrote:
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application futureproof.
I'm still wary of this approach because it puts the burden on 99%
of the code to be written (applications) instead of a small,
controllable s
Stanislav Malyshev wrote:
> Stefan Esser writes here:
> http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html
>
> that allow_url_include (and allow_url_fopen) can be easily worked around
> - i.e. extrenally-supplied code executed on server - by using php: and
> data: URLs.
On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
>Yeah, we probably should. Had a chat with Wez about it too. Here is
>the patch. I think this catches the cases we are interested in:
>
> http://lerdorf.com/php/is_url.diff
>
>If someone could double
Stefan Esser writes here:
http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html
that allow_url_include (and allow_url_fopen) can be easily worked around -
i.e. extrenally-supplied code executed on server - by using php: and
data: URLs. I think if we want allow_url_inclu
Nuno,
there is a simple answer to your email:
stick your anti Esser propaganda deep into some place noone is
interested in.
Before I posted about this, I brought this topic up MONTHS before PHP
5.2 was released. Even before this patch made it into PHP 5.2 from PHP 6
tree.
And now please die or
Nuno,
there is a simple answer to your email:
stick your anti Esser propaganda deep into some place noone is
interested in.
I was already expecting this kind of answer from you, but you clearly don't
know me.
The previous e-mail wasn't a personal attack nor an attack to your business,
nor I
Ilia Alshanetsky wrote:
On 4-Nov-06, at 11:18 AM, Christian Schneider wrote:
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application futureproof.
I'm still wary of this approach because it puts the burden on 99% of
the code to be written (applications) instead of a s
Hello Christian,
Sunday, November 5, 2006, 5:21:24 AM, you wrote:
> Ilia Alshanetsky wrote:
>> On 4-Nov-06, at 11:18 AM, Christian Schneider wrote:
>>> Ilia Alshanetsky wrote:
>> The language should ALWAYS have the best names possible to simplify
>> development, because that means convenience for
Marcus Boerger wrote:
We had problems with Date, DateTime and Time as all of those are common.
I'm well aware of this and the discussion around it.
Should we name a class that represents data and time info name after say
'PhpDateTimeFart' so that there is no problem? Because if you think furt
This one time, at band camp, Christian Schneider <[EMAIL PROTECTED]> wrote:
> But my favourite solution would be to
> a) have namespaces handling this issue
So, we've come full circle.
PHP does not support namespaces, so you should be prefixing.
Kevin
--
"Democracy is two wolves and a lamb
Would requests to a smbserver, e.g.
\\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.
Good point. Generally I'd say it belongs to the OS, but I'm not sure if
you can restrict this from OS side
> Never ever use a Status header.
As I mentioned in my email, I have used the HTTP string:
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://...";);
exit();
produces a 302.
header("Location: http://...";);
header("HTTP/1.1 301 Moved Permanently");
exit();
produces a 302.
head
Hi Nuno,
>
> I was already expecting this kind of answer from you, but you clearly
> don't know me.
> The previous e-mail wasn't a personal attack nor an attack to your
> business, nor I was doing any type of propaganda against you.
Calling my actions unethical and my posts pathetic is kinda a pers
20 matches
Mail list logo
