[PHP-DEV] testing
ignore this mail -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bundled gd
since gd is supposed to be bundled and packed together with php4.3 i just wanted to know if the patch for imagettftext for the truecolor rendering will be applied to its source, or if its allready has been - i wouldnt want it to be missed by accident if it is not then http://www.coupin.net/gd-freetype/ has the diff/source for gd2.0.1 which i believe is the latest one -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundled gd
if it is not then http://www.coupin.net/gd-freetype/ has the diff/source for gd2.0.1 which i believe is the latest one (snip cvs log) It was added and then removed.. hmm.. any case that could be added perhaps in a more imagecreatetruecolor friendly way, a patch is better than no patch, even if it doesnt allways work :/ or atleast a function which would convert a gd resource created with imagecreate() to a truecolor one, the opposite of imagetruecolortopalette() -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundled gd
hmm.. any case that could be added perhaps in a more imagecreatetruecolor friendly way, a patch is better than no patch, even if it doesnt allways work :/ or atleast a function which would convert a gd resource created with imagecreate() to a truecolor one, the opposite of imagetruecolortopalette() As I see in others GD function, allow it only only for true color image. wake up pa :-) What about allowing it only for truecolor images ? And just a thougt, making truecolor by default will be nice and make the code cleaner and easier to maintain, for all formats, comments ? actually, i agree on making everything truecolor by default, as long as ttftext gets fixed, and functions added gif support is not likely to be re-added, correct? perhaps you should really consider renaming this extension and functions instead of continuing a gd spinoff, im having trouble detecting wether i use gd1.x or 2.x allready, i had to parse phpinfo() for that. (subtile hint: perhaps having phpinfo() output xml code would be also good, or adding phpinfo_xml()) p.s. is development on the original libgd officially stopped and/or propertiary so there is no public CVS of its latest version? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundled gd
gif support is not likely to be re-added, correct? I added GIF Read-only support already. We cannot add Gif-write support until the Unisys patent expires next year. whats the status on the IMG_* constants then, i dont know about IMG_GIF_READ and/or IMG_GIF_WRITE, there is only IMG_GIF.. will those bits be set to 0 untill gif support is complete, and if not, why? my suggestion would be leave the RO support for gif in tact, and IMG_GIF bits set to false until the write support is returned and functional in read/write operations - p.s. the unisys patent is only an U.S. patent right? what about the non-us states? forced to wait until it expires? what happens after it expires, and can the expiration be somehow avoided from the unisys side (which would be a total drag) i didnt know patents can expire.. and it would be logical to assume there is some way to extend the ownership/validation - like domains etc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundled gd
i didnt know patents can expire.. and it would be logical to assume there is some way to extend the ownership/validation - like domains etc Yes, they do. Once it expires, it becomes public domain, of sorts. IANAL, but I do know that this is a big intellectual property issue here in the US. Once that patent expiration comes around, GD should be free to enable the writing of GIF formatted files. It is the quivalent of a pharmaceutical (drug) becoming available for competing companies to make generic versions of it. hmm, why not write an uncompressed-gif saver -- this would circumvent the patent since its on the acctual lzw compression, and seeing that there is none you wouldnt be in any kind of breach of the patent.. after the patent expires the lzw compression just gets included back i know there are size drawbacks here in the gif's generated, and probablly some code drawbacks since no gd version supported saving of uncompressed gif files, meaning someone would have to code that, the side effect would be the obvious, people would try to switch to png since it's lossless and gives out smaller files -- but the GIF support would be fully functional as far as saving goes this would be a good idea for 4.3 (i understand the bundled lib will be included with 4.3 already, right?), i dont see a reason in adding extra defines for read_only etc, if you can circumvent the patent just by not using lzw (until the patent expires, which should be by the time 5.0 comes out - hopefully) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundled gd
imho, GIF format is dead, still used but dead ;) Providing read functions is enough. I prefer to see a mng support in futur versions (http://www.libmng.com/) backwards compatibility is still backwards compatibility.. either you support it full, or you dont support it at all. as for having an uncompressed gif writer.. that would cause a lot of people to use other alternatives, like png. still thinking this readonly thing sucks (not that i'dd ever probablly use gif writing.. i guess its just that having something once for free means you're going to have it forever, or atleast it should) black -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REVIEW: Imminent session patch
(snip).. There is however another problem, which I believe should be addressed. The problem being that session_register() function does not work unless the user has register_globals enabled. This particular problem causes problems for anyone using php software that was written before this limitation was added. In fact the sessions tests inside ext/session/tests fail for that very reason. correct me if i am wrong, but with $_SESSION you dont even need to have session_register() anymore, as for the behaviour of session_register(), if it held up to the latest php version, i dont see any sense of changing its functionality now, it's a less logical step than to encourage people to use $_SESSION. personally i think session_register() should have been removed after the creation of $_SESSION, but i see the logics in backwards compatibility, but for the future of php (php5.0.0) maybe some functions like this one should acctually be removed in favour of $_SESSION addressing. regards, black -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patches and Extensions and Such
1. Does adding the ?HIGHLIGHT_FORMAT switch to the .phps file format
reduce or degregate current / existing functionality in any way? {if yes,
please expand)
No, but since no one has given any reason why line numbers should not
be on all the time, why bother with it? Just turn them on all the time.
+1 from me on all points, having line numbers there is just down right
usefull.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
IP match makes no sense. Someone's ip can change dramatically from one click to the next due to dhcp leases timing out, roaming from one wireless gateway to the next, coming through a round-robin dns batch of proxy servers, etc. i quote myself: p.s. storing IP/USERAGENT/whatnot on the server, matching it with the SID would probablly decrease the number of session hijackings, i just dont know if that behaviour should be the default one. imo, letting the user change it in php.ini would be more appropriate in case somebody see's a problem inside this? *php.ini* - ie, set by admin/owner.. maybe ini_set() would also be nice. i ofcourse see your point in not matching ip, but if you dont want session hijackings, you really just do have theese options.. personally you can allways write this in 5 lines of php code which is just in a standard include file somewhere, to start the session and check useragent/remoteaddr inside the $_SESSION vars if they match the current visitor.. and people do that. if the useragent changes then its almost certain that you have a session hi-jacking (or an idiot pasting an url with the SID from browser1 to browser2), which is something we dont want, but with browsers today we dont get very many useragents (or unique ones..), the trick should be to get something UNIQUE from the browser, something that doesnt change (or atleast, shouldnt) the ideal sollution is to make atleast the useragent check, because it SHOULDNT change, and this should be default and non-configurable... ofcourse you can have two machines with the same browser and useragent (and you acctually have lots of those), but still you eliminate *some* risk of session hi-jacking, making it still work in an environment you suggested the ip match should be implemented too, but trough a php.ini switch, since i see how that behaviour might not be desired from your comment above, i would default it to off thou, let the user/admin/whatnot change it if they desire to do that. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
maybe you should implement a dynamic_sid flag, which would make SID behave in the following way page.php?sid=sidvaluekey after you would visit that page, you would get all url's in the page encoded with page.php?sid=newvaluekey so basically, the SID value expires (or should i say mutates) on each pageload, this can be done with set-cookie or in url, either way, the only problem still exists if people paste page.php?sid=newvaluekey before they acctually visit it. p.s. storing IP/USERAGENT/whatnot on the server, matching it with the SID would probablly decrease the number of session hijackings, i just dont know if that behaviour should be the default one. imo, letting the user change it in php.ini would be more appropriate in case somebody see's a problem inside this? matching ip limits the number of session hijackings to atleast the same network you are on (behind a fw/router which does nat), and the users who use the same http proxy as you (in case you use one) so its either expire/generate (rotate,morph,mutate) SID on each pageload, or the more popular sollution... IP match - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Sascha Schumann [EMAIL PROTECTED] Cc: Yasuo Ohgaki [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, August 20, 2002 12:27 AM Subject: Re: [PHP-DEV] trans-sid warning? Well, while it is true that it is impossible to completely prevent, our current setup doesn't do anything at all to prevent it which makes the attack much simpler. There is currently no need for the attacker to visit the site to be attacked at all and thus he doesn't need any keepalive stuff to make sure the SID stays active. He can simply make up any SID he wants and trick the victim into visiting the site. As soon as the attacker sees that a victim has clicked, he can follow that victim in since there is no check in PHP that ensures that a SID is a valid active session. I don't see any reason to allow visitors to specify their own custom SID. What is the benefit to that? -Rasmus On Mon, 19 Aug 2002, Sascha Schumann wrote: Well, more worrisome would be if a bad guy tricks you into clicking on a link or simply sends you an image in an email that makes a request to my server with a valid-looking session id. Then if you go to this site (that I've debunked that scenario already a few times. The net result is that this class of attacks is impossible to prevent. The assumption in your scenario and the following is this: The attacker has access to a script X which calls session_start(). My scenario: 1.) Attacker A accesses X and stores the SID which PHP assigns to him. 2.) A crafts a link containing SID and sends it to victim V. 3.) A keeps SID alive by repeatedly accessing X using SID. 4.) V opens link and authenticates. 5.) A's script notices (4). A can overtake V's session. - Sascha -- 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: black
translating the manual to the slovene language occasional bug smashing/tracking | feature requests
Re: [PHP-DEV] W3C html validation issue
(snip)
on the amp; subject.. i pressume this is a html only thing, if i try a
header(Location .$url), where $url has amp;'s in them php failed to
recognise variables from that..
if the link is made inside an a tag in the same way i didnt experience
this problem (using IE5.0 5.5 and 6.0), so i pressume the browser converts
the amp; to in the GET request.
i dont know if it still does that as i havent had time to test it, but
basically amp; works fine in html tags and similar, and you better do a
str_replace('amp;','',$url) for header(Location: .$url); since explorer
doesnt convert it, i haven't tried with the rest of the browser pool
available ..
p.s. if i set arg_separator.output = amp;
... if i have a file.php?bla=foofoo=bar its going to define $_GET['bla'] =
foofoo=bar ?
p.p.s. if thats a yes, perhaps you can add multiple options to
arg_seperator.output ? so you can define them by priority, first parse amp;
then parse , then parse ; ..
i just god the wierd idea of setting arg_seperator.output to ';'. please
stop me.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $GLOBALS
is there an alias to $GLOBALS .. seems kinda long to type.. if not, can i suggest $_ or is it taken anywhere? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bugpack 13
(warning) note that you cannot convert a partition back to fat32 in case you might want to. meaning, when youre on nfs you stay on nfs.. unless you reinstall. other than that nfs is for the better imo :) - Original Message - From: Magnus M [EMAIL PROTECTED] To: Michael Dransfield [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 03, 2002 12:20 PM Subject: Re: [PHP-DEV] Bugpack 13 On Tue, 02 Jul 2002 23:26:20 +0100 Michael Dransfield [EMAIL PROTECTED] wrote: i can help, but do you actually need NTFS? for some reason my pc was loaded with fat32 and win2k :-/ You can convert to ntfs with convert if you want it to be NTFS.. convert /FS:ntfs c: or something like that =) Try convert /? (snip) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend2 design arhitecture
[quote ZEND_CHANGES.txt] * Forced deletion of objects. .. yadda .. Note that if you have a user-defined function delete() in an old script, this script will yield a parser error with the Zend Engine 2.0, since 'delete' is now a reserved word. [/quote] if you chose internal functions for constructors, destructors, object cloning, and other runtime-critical-operations to have a prefixed __, why did you choose delete over __delete ? regards, black -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] code profiler
ok this may be a bit offtopic, but here goes i am searching for a PHP code profiler, something to measure key components of the PHP scripts, tracking how many function calls are preformed in the code, the cost of each of the functions in terms of cpu cycles and memory usage, minimal, maximum, and average, etc, basically to help me optimise my code and maybe make some nice statistics along with that.. as far my search has been unsucessfull, i did come to find an old message from [php-dev] list, from a Brian Moore and i tried to contact him with no luck, and not beeing able to chase up anything on the subject.. http://www.zend.com/lists/php-dev/200108/msg01181.html and i did find some old (read 3.0.16 version php) profilers on sourceforge/freshmeat are there any plans to have that in latest versions of php in a module or similar? something run-time would be also great, so i can get the profile with php, after the code finished executing.. this was posted on php-dev since it should involve somekind of more lowlevel php coding, so i guess this is a feature request... and it probablly gets the same audience as bugs.php.net so, any info where i can start if i want to profile my php code? (or how i can start developing and extension, if php lets you go that deep into the scripting engine with its extensions) regards, black
Re: [PHP-DEV] Switching zlib.output_compression, bug #16109
imo its not really a bug, but its nice to have a workaround,.. php is very
developer-user friendly, and people get used to it by seeing it work from
the start, and having support/manual if it doesnt..
also, output compression should be only achieved by
ob_start(ob_gzhandler); since then people would acctually (maybe?) think
of what they are trying to compress. also an updated manual note would be
good for that... the bugfix below is just taking it one step too far imo,
so i have to agree with Mike in part, that it is Netscape's responsibility,
but since old netscape browsers development has stopped something has to be
done in PHP to make it work correctly on those too.
bugfix = workaround = sollution :)
(ofcourse you know this means you will be teaching the kids wrong dogma
about programming, if you solve all their problems for them,... fix a
persons problem and you are frustrated for one day, teach them how to code
and they will be frustrated for a lifetime :))
(my (evil) 5 cents)
Tit
- Original Message -
From: Mike Hall [EMAIL PROTECTED]
To: Stefan Roehrich [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, June 24, 2002 4:41 PM
Subject: Re: [PHP-DEV] Switching zlib.output_compression, bug #16109
I would venture that this is a bug in Netscape, not a bug in PHP and
therefore not PHP's responsibility to fix.
Netscape is reporting to PHP that it accepts zipped content, when it
clearly
doesn't accept zipped images.
Mike
- Original Message -
From: Stefan Roehrich [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 24, 2002 3:23 PM
Subject: [PHP-DEV] Switching zlib.output_compression, bug #16109
Hello!
There has been a bug report (#16109) about a bug in Netscape 4.79,
which doesn't display images if Content-Encoding: gzip is used. After
thinking about a browser detection config flag for zlib.output
compression, at LinuxTag we discussed, that a more general solution
would be better, that means switching off output compression for
images and let it be possible to switch it off (or force it on) during
script execution.
So I implemented it this way:
The headers for output compression are sent late, not in the zlib
request init, but in the SAPI send_headers call, I think this is the
latest possible time I can add it, so that it's possible to switch it
off before that time. If you send a header(Content-Type: image/xxx)
output compression is switched off, you can also switch it off via
ini_set('zlib.output_compression', 'Off') (or force it on, if you use
this call with 'On' after the image header was sent, but this only
works, if it was globally enabled, you can't switch it on during
script execution if the default says 'Off' (you need the output
buffering, you also can't change the buffer size)).
If output compression was disabled during the script, the compression
handler simply does noething and no headers are added (so you can
switch the setting only before the headers are sent).
Because I'm no SAPI expert and I don't know, if there are some other
effects, if I add the header in the send_headers call, I haven't
commited it yet, see the attached patch. If nobody objects, I'll
commit it in a few days.
Stefan
--
Stefan Röhrich [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.roehri.ch/~sr/
--
--
--
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
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Switching zlib.output_compression, bug #16109
let me get this straight.. you can turn off output_buffering = on inside php? then whats the problem with zlib, just make it output_buffer, and AFTER that check the ini value, weather to compress that data or not.. so it could be turned off runtime, or am i wrong? - Original Message - From: Mike Hall [EMAIL PROTECTED] To: Jaime Bozza [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 24, 2002 5:31 PM Subject: Re: [PHP-DEV] Switching zlib.output_compression, bug #16109 I never set it in the ini, only set it at runtime. - Original Message - From: Jaime Bozza [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'Mike Hall' [EMAIL PROTECTED] Sent: Monday, June 24, 2002 4:31 PM Subject: RE: [PHP-DEV] Switching zlib.output_compression, bug #16109 Ok, so... Say you have php.ini that defaults zlib.output_compression to On? How would you go about setting it to off inside the script that sends out an image? Jaime Bozza -- 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
