php-general Digest 16 Dec 2006 23:24:21 -0000 Issue 4518
Topics (messages 245912 through 245920):
Re: Problems with Zip+IE6
245912 by: Roman Neuhauser
Re: How php works?
245913 by: Kai Xiang
245915 by: Robert Cummings
245916 by: Roman Neuhauser
245917 by: Robert Cummings
Re: php redirection..
245914 by: Stut
245920 by: Jonesy
Re: imap_open('/path/to/mbox', '', '')
245918 by: Richard Lynch
problem with imagecreate on new webserver
245919 by: macha.kingdomsend.com
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
php-general@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
# [EMAIL PROTECTED] / 2006-12-15 22:55:54 -0600:
> On Tue, December 12, 2006 11:04 am, Frank M. Kromann wrote:
> > if you use:
> >
> > header("Content-Type: application/zip");
> > header("Content-Disposition: attachment; filename=\"somefile.zip\"");
> >
> > That works for me with IE 6/7 and other browsers.
>
> Argggggh.
>
> Please read this:
> http://richardlynch.blogspot.com/
>
> Go test with MORE browsers and MORE OSes, because you haven't yet hit
> the ones where your Content-Disposition does not work, and they are
> out there somewhere.
As if it mattered that much. The filename's just a hint, the browser
can be configured to ignore it even if it understands it, whatever.
I would even say you're bound to hit a browser configured for some
unintelligent reason to handle all app/o-s files with winamp. So what?
You cannot count on anything the UA will/not do to the content.
BTW, the "1995 johnny-come-lately Microsoft made-up Content-disposition
header" has been proposed for MIME by Qualcomm (RFC1806, RFC2183).
HTTP/1.1 (RFC2616) says:
15.5 Content-Disposition Issues:
RFC 1806 [35], from which the often implemented Content-Disposition
(see section 19.5.1) header in HTTP is derived, has a number of very
serious security considerations. Content-Disposition is not part of
the HTTP standard, but since it is widely implemented, we are
documenting its use and risks for implementors. See RFC 2183 [49]
(which updates RFC 1806) for details.
[...]
19.5.1 Content-Disposition
The Content-Disposition response-header field has been proposed as a
means for the origin server to suggest a default filename if the user
requests that the content is saved to a file. This usage is derived
from the definition of Content-Disposition in RFC 1806 [35].
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
An example is
Content-Disposition: attachment; filename="fname.ext"
The receiving user agent SHOULD NOT respect any directory path
information present in the filename-parm parameter, which is the only
parameter believed to apply to HTTP implementations at this time. The
filename SHOULD be treated as a terminal component only.
If this header is used in a response with the application/octet-
stream content-type, the implied suggestion is that the user agent
should not display the response, but directly enter a `save response
as...' dialog.
See section 15.5 for Content-Disposition security issues.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--- End Message ---
--- Begin Message ---
On 12/16/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Fri, December 15, 2006 3:32 am, Kai Xiang wrote:
> Oh, that's interesting to know, is that from certain test of design
> goals? I
> suspect this for I thought the most time-consuming work in PHP should
> be
> compiling.
The most time consuming work in PHP isn't in PHP at all. :-)
It's in the database, the file system, the network congestion...
It's true, that for the core of PHP, for what little time is spent by
PHP doing anything at all, compiling the code to opcode takes longer
than ripping through those opcodes and dispatching the function call
to some external library, not counting the time spent outside of PHP
core actually executing whatever that extension library does.
That still doesn't mean that the actual process of converting PHP
"echo" to opcode #42 takes any large chunk of time. It's very tiny.
> Refer to the early descussion, because all the thread share the same
> opcode, so it could save memory usage at the same time, is that true?
> say if
> there is a lot of requests at the same time, that could be a lot of
> memories. is that the design goal? or why not just implement a PHP
> file
> cache.
Because if you just did the file cache, it would be an equal amount of
work to doing the opcode cache, so you might as well go ahead and
cache the opcode, and save that extra 1% performance.
Caching the parser output as opcodes instead of raw PHP input is like
free gravy. :-)
It's a question of inserting your cache calls in line 1470 or line
1530, and you either cache the PHP source at 1470, or the opcode
output at 1530. So you do it at 1530 and save those lines of code in
between that do the opcode translation.
[line numbers used for illustrative purposes, and are not actual line
numbers, nor even realistic range between them]
That's really useful information, thanks
> 2. Is there some alternative choise except zend engineen, why need
>> a
>> > zend
>> > engine? for performance advantage or just easy for porting to
>> > different
>> > platform?
You could, in theory, take PHP, rip out its guts (aka the Zend Engine)
and replace it with some other compiler/parser/engine that did much
the same thing, if you had nothing better to do with your life for the
next several years...
I'm just curious, I'll save more time for fun... :)
The Zend Engine is what translates:
if (...){
myfunction(...);
}
into something that the computer can actually execute.
That's pretty much all it is.
Note that the Zend Engine is OPEN SOURCE and it will always be OPEN
SOURCE and it will never not be OPEN SOURCE and it is FREE and it will
always be FREE and it will never not be FREE (*) for PHP.
But, sure, if you feel strongly enough about it, go ahead and fork the
PHP project to rip out the Zend Engine and write your own.
[shrug]
That's why it's Open Source, to give you the freedom to do that.
Seems like an awful lot of work to no real purpose to this naive
reader, but to each their own.
(*)
Actually, if somebody wants to embed the ZE inside of something other
than PHP, then I think Zend expects to get paid for that. I do know
they had a deal or two on the table when I worked for them, back in
2000 or so, but I dunno if they came to fruition or not. ZE may well
be embedded in some telecom gear somewhere, as it would be a good fit
for a simple scripting language that is small enough (without
extensions) to fit in that niche market. And the telco industry can
afford whatever Zend charged them for that, most likely.
Yes, we know there is a possibility that Opensource can make money, and
bring value for those who don't want to pay at the same time..
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--- End Message ---
--- Begin Message ---
On Sat, 2006-12-16 at 19:58 +0800, Kai Xiang wrote:
> On 12/16/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
> > (*)
> > Actually, if somebody wants to embed the ZE inside of something other
> > than PHP, then I think Zend expects to get paid for that.
I don't think so... the PHP and Zend licenses are quite liberal with
very few restrictions. Namely that you don't call your software php or
use php in the name (something many packages seem to ignore (either that
or they got permission)). The Zend license is practically a clone of the
PHP license with a search and replace for PHP to Zend :) There's nothing
that says you have to pay to embed it in your own software. That said,
if you make a product that uses either the PHP or Zend engine and makes
oodles of money, I think you should feel somewhat morally obliged to
give back in some way.
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. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
# [EMAIL PROTECTED] / 2006-12-16 07:24:49 -0500:
> On Sat, 2006-12-16 at 19:58 +0800, Kai Xiang wrote:
> > On 12/16/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
> > > (*)
> > > Actually, if somebody wants to embed the ZE inside of something other
> > > than PHP, then I think Zend expects to get paid for that.
>
> I don't think so... the PHP and Zend licenses are quite liberal with
> very few restrictions. Namely that you don't call your software php or
> use php in the name (something many packages seem to ignore (either that
> or they got permission)). The Zend license is practically a clone of the
> PHP license with a search and replace for PHP to Zend :) There's nothing
> that says you have to pay to embed it in your own software. That said,
> if you make a product that uses either the PHP or Zend engine and makes
> oodles of money, I think you should feel somewhat morally obliged to
> give back in some way.
Sorry if I take this OT, but when I publish my work under the MIT license,
I mean it. Anything else would be hypocrisy. OSS is not beggarware.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--- End Message ---
--- Begin Message ---
On Sat, 2006-12-16 at 15:59 +0000, Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2006-12-16 07:24:49 -0500:
> > On Sat, 2006-12-16 at 19:58 +0800, Kai Xiang wrote:
> > > On 12/16/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
> > > > (*)
> > > > Actually, if somebody wants to embed the ZE inside of something other
> > > > than PHP, then I think Zend expects to get paid for that.
> >
> > I don't think so... the PHP and Zend licenses are quite liberal with
> > very few restrictions. Namely that you don't call your software php or
> > use php in the name (something many packages seem to ignore (either that
> > or they got permission)). The Zend license is practically a clone of the
> > PHP license with a search and replace for PHP to Zend :) There's nothing
> > that says you have to pay to embed it in your own software. That said,
> > if you make a product that uses either the PHP or Zend engine and makes
> > oodles of money, I think you should feel somewhat morally obliged to
> > give back in some way.
>
> Sorry if I take this OT, but when I publish my work under the MIT license,
> I mean it. Anything else would be hypocrisy. OSS is not beggarware.
I'm not sure I understand the point you are making :/
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. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
Casey Chu wrote:
Well... They skip all <!-- -->'s, so they skip <script><!--
//--></script>'s.
And you *know* this how?
They may well skip comments in terms of what content actually gets
indexed, but I would expect their indexer is smart enough to parse HTML
comments in a script block as though it were not in an HTML comment
because that's what a browser does. What they actually do with that
content - execute it, or just analyze it, or whatever - we don't know.
You can't make sweeping statements like that unless you can back it up
with at least one reference, preferably official.
-Stut
On 12/15/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Fri, December 15, 2006 10:28 pm, Casey Chu wrote:
> Actually... Search engines don't have a JavaScript interpreter.
Actually...
You don't know for sure that Google isn't using Perl's javascript
interpreter.
Unless you work for Google, have just told us something they would
consider double-secret proprietary, and are about to get fired.
:-) :-) :-)
It would not be Rocket Science for a search engine to execute the
javascript on a page in a sandbox, to analyze it for abuses, viruses,
and other things they wanted to take away "points" for.
I know I could almost manage that with a ton of work.
And I figure the Google engineers are probably a heck of a lot smarter
than I am, and for sure they are way more experienced.
So I'm going to assume that any "dodge" in JS I could come up with to
game their system, will be detected and defeated as soon as they want
to bother doing that.
But, hey, feel free to get Google to issue a statement that they do
not now nor ever will check the JS on sites as they index them, and
point to it as a reference.
:-)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On Fri, 15 Dec 2006 21:07:44 -0800, Casey Chu wrote:
> Well... They skip all <!-- -->'s, so they skip <script><!-- //--></script>'s.
Wow! You get The Prize for the best non sequitor of the day.
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
*** Killfiling google posts: <http//jonz.net/ng.htm>
--- End Message ---
--- Begin Message ---
On Sat, December 16, 2006 4:39 am,
[EMAIL PROTECTED] wrote:
>> Would converting Un*x newlines to Windows on the entire mbox help?
>> Seems to me that the RFC is quite specific about the newlines of
>> headers and body, and converting the mbox in toto is unlikely to be
>> useful.
> you shouldn't be transferring the mbox file as a binary ftp. the file
> is a text file, that is sensitive to the CR/LFs. by moving it binary
> you're not getting the unix->dos CR/LF conversions. do an ascii ftp
> transfer and see if that helps.
>
> that may not resolve your problem, but that was the one thing that
> stood out.
I have since done a simple test on a one-email mbox, converting Un*x
newlines to Windows newline in PFE, and it didn't help.
To complete the test, I suppose I should binary FTP the one email mbox
back up to the Linux box and make sure imap_open can read it, but
since it's an excerpt of the 14000 message mbox that imap_open can
already read on the Linux box, I'd be pretty surprised if Linux
imap_open can't read a snippet from a file it can already read...
I'll probably do that and file it as a bug report if I don't make any
progress on any other front.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--- End Message ---
--- Begin Message ---
i am moving my webserver from a windows box to a linux box with php ver
5.2.0 and noticed i am having a problem with a php file(code below). i
thought it was a module i was missing but looking at the php config
file all the same modules are loaded. allow_url_fopen is enabled. what
would i be missing in the php install that would make this code not
work correctly from one machine to the other.
when loading on the new box all i get is a image with
'http://localhost/imgfile.php'
<?
session_start();
define( 'SITE' , 'http://localhost' );
//define 7char code
$md5 = md5(microtime() * mktime());
$string = substr($md5,0,7);
//create image
header("Content-type: image/png");
$img= imagecreatefrompng(SITE. '/images/img.png');
$white = imagecolorallocate($img, 233, 239, 239);
$line = imagecolorallocate($img,233,239,239);
for ($i = 1; $i <= 5; $i++) {
$x1 = rand(1,149);
$x2 = rand(1,149);
$y1 = rand(1,49);
$y2 = rand(1,49);
imageline($img, $x1, $y1, $x2, $y2, $line);
}
//put code in image
imagestring($img, 5, 35, 25, $string, $white);
//save key to session
$_SESSION['key'] = md5($string);
imagepng($img);
?>
--- End Message ---
