Re: [PHP] imap_open('/path/to/mbox', '', '')

2006-12-16 Thread Jochem Maas
Richard Lynch wrote:
 I'm having trouble with Windows imap_open.
 
 I have the exact same mbox on a Linux box, with the exact same PHP
 code opening it just fine.
 
 I FTP (binary) to the Windows box (and a second time to be sure it
 wasn't an FTP flake-out).
 
 Opening the mbox in Windows yields a message like:
 PHP Notice:
 Unknown:
 C:\\data\\mbox.excerpt (file C:\\data\\mbox.excerpt) is not in valid
 mailbox format (errflg=2)

LONG SHOT: the path is freaking imap_open out - maybe it can be tricked
by using a path like so '/data/mbox.excerpt' (which windows should swallow -
although it assumes C: is the default drive [I think])

other than that I can only think to switch the line-endings in the mbox file
(at least to rule out the line ending as the problem)?!


...

 
 Can somebody point me to anything that would de-mystify (errflg = 2)
 in the error message?
 Obviously that '2' has SOME kind of meaning, but is that from PHP,
 IMAP, Windows OS, File System, ...?

I think the errflg is coming from IMAP ... I have found several bits
of C code related to IMAP (and seemingly nothing to do with php)
that reference 'errflg' - I have also found
that a value of 2 for errflg can mean anything from 'invalid mbox format'
to 'authentication failed'  (not very helpful!)

what do these functions return for you?:

imap_errors(),  imap_alerts(), imap_last_error()

 
 

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



Re: [PHP] Problems with Zip+IE6

2006-12-16 Thread Roman Neuhauser
# [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.
 
 Argh.
 
 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

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



Re: [PHP] How php works?

2006-12-16 Thread Kai Xiang

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?




Re: [PHP] php redirection..

2006-12-16 Thread Stut

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






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



Re: [PHP] How php works?

2006-12-16 Thread Robert Cummings
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.  |
`'

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



Re: [PHP] How php works?

2006-12-16 Thread Roman Neuhauser
# [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

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




Re: [PHP] How php works?

2006-12-16 Thread Robert Cummings
On Sat, 2006-12-16 at 15:59 +, 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.  |
`'

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



Re: [PHP] imap_open('/path/to/mbox', '', '')

2006-12-16 Thread Richard Lynch
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?

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



[PHP] problem with imagecreate on new webserver

2006-12-16 Thread macha
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);
?

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



[PHP] Re: php redirection..

2006-12-16 Thread Jonesy
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

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



Re: [PHP] Re: php redirection..

2006-12-16 Thread Casey Chu

I believe it's spelled non-sequitur. =)

On 12/16/06, Jonesy [EMAIL PROTECTED] wrote:

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

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




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