[PHP-DEV] RFC: Removal of dead SAPIs
Maybe is time to vote and implement it in php 7 with a pull request for each sapi https://wiki.php.net/rfc/removal_of_dead_sapis tux is dead for almost 10 years thttpd does have a fork that seems maintained from git log http://opensource.dyc.edu/sthttpd http://opensource.dyc.edu/gitweb/?p=sthttpd.git;a=summary
Re: [PHP-DEV] RFC: Removal of dead SAPIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 18/09/2014 11:08, marius adrian popa a écrit : Maybe is time to vote and implement it in php 7 with a pull request for each sapi https://wiki.php.net/rfc/removal_of_dead_sapis AFAIK, litespeed is not dead It have be recently updated to latest LSAPI Remi P.S. http://git.php.net/?p=php-src.git;a=history;f=sapi/litespeed/lsapilib.c;h=aac823fc1c6408207ef0aa3ee29d81b57bea69de;hb=refs/heads/PHP-5.6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQaouQACgkQYUppBSnxahh1VACgmZSjwVjBgsy1BHnHXqEYTbGC sasAnj6BtuuHTEMWhodj/BPzpQAeDwGc =SD7e -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On Sep 17, 2014, at 11:40, Matthew Fonda mfo...@php.net wrote: Hi Andrea, This is great -- thanks to you and Nikita for the work here. Syntax wise, I would prefer a function-like syntax, e.g. coalesce($a, $b, 'c') or ifsetor() instead of $a ?? $b ?? 'c'. I find this more readable, and it avoids any possible confusion about precedence within the expressions. Either way, still +1 for this feature. Best regards, --Matthew I’m STRONGLY +1 in favor of this operator, ASAP; I’ve had to write more than a few hacks to keep a large codebase I’m responsible from being a complete mess of isset() checks - 5.6 has saved me a lot of what used to be ugly workarounds (variadic functions anyone?), but this one still haunts me. I would argue for both coalesce() (as a language token) and ?? and ??=, as shorthand forms, giving the user a choice as to which they find more readable. ?? is standard in both .NET and Apple’s Swift language - Apple added it to Swift (including the chaining behavior) early during the beta cycle due to user demand for exactly this kind of logic, and it’s been part of C# for a long time. -- Gwynne Raskind -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
I'm seeing '??' as analogous to the way JS developers use '||', and I use that all the time when writing JS. Personally I wouldn't be interested in a function version because the short-circuiting of '??' is an important distinction; not something you can replicate with a function. Therefore having both would be confusing IMO. Also, not much sure about a '??=', perhaps it should be a followup RFC should '??' be accepted. On 18 September 2014 10:26, Gwynne Raskind gwy...@darkrainfall.org wrote: On Sep 17, 2014, at 11:40, Matthew Fonda mfo...@php.net wrote: Hi Andrea, This is great -- thanks to you and Nikita for the work here. Syntax wise, I would prefer a function-like syntax, e.g. coalesce($a, $b, 'c') or ifsetor() instead of $a ?? $b ?? 'c'. I find this more readable, and it avoids any possible confusion about precedence within the expressions. Either way, still +1 for this feature. Best regards, --Matthew I’m STRONGLY +1 in favor of this operator, ASAP; I’ve had to write more than a few hacks to keep a large codebase I’m responsible from being a complete mess of isset() checks - 5.6 has saved me a lot of what used to be ugly workarounds (variadic functions anyone?), but this one still haunts me. I would argue for both coalesce() (as a language token) and ?? and ??=, as shorthand forms, giving the user a choice as to which they find more readable. ?? is standard in both .NET and Apple’s Swift language - Apple added it to Swift (including the chaining behavior) early during the beta cycle due to user demand for exactly this kind of logic, and it’s been part of C# for a long time. -- Gwynne Raskind -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pete Boere Web Developer
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On 18 Sep 2014, at 12:32, Pete Boere p...@the-echoplex.net wrote: I'm seeing '??' as analogous to the way JS developers use '||', and I use that all the time when writing JS. PHP already has a direct equivalent to ||, namely the ?: operator. However, unfortunately PHP always spits out a notice on non-existent indices, unlike JS which just results in undefined, so we need to add a special operator to silence it. Personally I wouldn't be interested in a function version because the short-circuiting of '??' is an important distinction; not something you can replicate with a function. Therefore having both would be confusing IMO. We could use a function *syntax*, though, but I don’t like this idea. coalesce() and ifsetor() are both ugly to me, and it’s not super obvious what they do: var_dump(coalesce($_GET[‘foobar’], 3)); vs. var_dump($_GET[‘foobar’] ?? 3); ?? also has the advantage of being shorter. Also, not much sure about a '??=', perhaps it should be a followup RFC should '??' be accepted. It’d make sense to do it within this RFC if possible. If it seems too controversial, it could always have a separate vote within the RFC. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
Pete Boere wrote (on 18/09/2014): I'm seeing '??' as analogous to the way JS developers use '||', and I use that all the time when writing JS. Actually, JS's || is more analogous to the existing ?: operator, because it checks for truthiness, not definedness (!empty() rather than isset(), in PHP terms). PHP: echo false ?: ?: 0 ?: default; JS: console.log( false || || 0 || default ); The behaviour around undefined variables is a bit different, but that's a property of JS as a language, not any suppression by the || operator (console.log(x) with undefined x is an error; console.log(x.y) with x as an empty object is not). -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.5.17RC1 is ready for testing
What's the benefit of doing a Release Candidate/QA cycle when fixes for regressions aren't merged to the final release? See https://bugs.php.net/bug.php?id=67965 Regression reported and fixed, but fix not merged to 5.5.17 branch. Commit https://github.com/php/php-src/commit/f86b2193a483f56b0bd056570a0cdb57ebe66e2f?diff=unified File in 5.5.17: https://github.com/php/php-src/blob/PHP-5.5.17/ext/openssl/xp_ssl.c#L884 Not critical enough? Just missed it? RC releases just for the show? :? Arjen On 09/05/2014 02:04 PM, Arjen Schol wrote: Hi Julien, I've found a regression in stream_select with TLS. Testscript and details at https://bugs.php.net/bug.php?id=67965 Thanks, Arjen On 09/04/2014 12:17 PM, Julien Pauli wrote: Hello PHP 5.5.17 RC1 is available for testing. You can download it from http://downloads.php.net/jpauli/ The Windows binaries are available at http://windows.php.net/qa/ This release contains a number of bugfixes. For the list of bugfixes that you can target in your testing, please refer to the NEWS file: https://github.com/php/php-src/blob/php-5.5.17RC1/NEWS Please test it carefully, and report any bugs in the bug system. The stable release is planned for September 18th, if no critical issues will be discovered in the RC. Thank you for your support. Julien Pauli David Soria Parra -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On Thu, 2014-09-18 at 12:41 +0100, Andrea Faulds wrote: We could use a function *syntax*, though, but I don’t like this idea. coalesce() and ifsetor() are both ugly to me, and it’s not super obvious what they do: var_dump(coalesce($_GET[‘foobar’], 3)); vs. var_dump($_GET[‘foobar’] ?? 3); ?? also has the advantage of being shorter. If you don't now what ?? does it's far from obvious. coalesce is a term that can be put into google and will deliver results. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On 18 September 2014 14:34, Johannes Schlüter johan...@schlueters.de wrote: On Thu, 2014-09-18 at 12:41 +0100, Andrea Faulds wrote: We could use a function *syntax*, though, but I don’t like this idea. coalesce() and ifsetor() are both ugly to me, and it’s not super obvious what they do: var_dump(coalesce($_GET[‘foobar’], 3)); vs. var_dump($_GET[‘foobar’] ?? 3); ?? also has the advantage of being shorter. If you don't now what ?? does it's far from obvious. coalesce is a term that can be put into google and will deliver results. On the flip side, coalesce() etc would introduce another keyword, which would be a BC break, unless we also manage to get keywords-as-identifiers working and accepted for the same release. I wouldn't mind betting there are quite a few applications out there with a function/method called coalesce() defined... I know there's at least one, because I work on it regularly, and github has over 100,000 hits for it (the vast majority of these are in SQL strings but I still found 4 PHP functions/methods on the first 3 pages): https://github.com/search?q=coalesce+language%3Aphptype=Code -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
On Sep 18, 2014 9:36 AM, Johannes Schlüter johan...@schlueters.de wrote: On Thu, 2014-09-18 at 12:41 +0100, Andrea Faulds wrote: We could use a function *syntax*, though, but I don’t like this idea. coalesce() and ifsetor() are both ugly to me, and it’s not super obvious what they do: var_dump(coalesce($_GET[‘foobar’], 3)); vs. var_dump($_GET[‘foobar’] ?? 3); ?? also has the advantage of being shorter. If you don't now what ?? does it's far from obvious. coalesce is a term that can be put into google and will deliver results. johannes It would (I assume) be described as such on the Comparison Operators manual page, leading one to Google coalesce. If I don't know what an unfamiliar operator does in a language, its operators documentation page is a logical first stop.
Re: [PHP-DEV] RFC: Removal of dead SAPIs
Hi Marius, On Thu, September 18, 2014 11:08, marius adrian popa wrote: Maybe is time to vote and implement it in php 7 with a pull request for each sapi https://wiki.php.net/rfc/removal_of_dead_sapis tux is dead for almost 10 years thttpd does have a fork that seems maintained from git log http://opensource.dyc.edu/sthttpd http://opensource.dyc.edu/gitweb/?p=sthttpd.git;a=summary the idea was to have the list of items ready for removal before the voting. But I still couldn't come to make all the necessary TODOs for that (those are mentioned in the RFC). I'm aware of that RFC but unfortunately still far from going on. If you or anyone else is in the mood to take over, at least for some parts, we could have it earlier. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Why does checkdnsrr() default to MX??
Hey guys, I just spent some time troubleshooting what appeared to be a DNS issue before I realized that, absent the optional $type argument, checkdnsrr() defaults to MX. Can anybody explain why it's defaulting to MX and not ANY? It seems really counter-intuitive. --Kris
[PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL
Hello, I'm working on enhancing the FILTER_VALIDATE_URL filter ( https://github.com/php/php-src/pull/826). The current implementation does not support validation of internationalized domain names (i.e: http://www.académie-française.fr/ http://www.xn--acadmie-franaise-npb1a.fr/). Support of IDN validation can be easily added using ICU's uidna_toASCII() function. Is it acceptable to add a dependency to ICU for ext/filter? Another option is to add a HAVE_ICU constant in main/php_config.h and to validate IDN only if ICU is present. What strategy is preferred? -- Kévin Dunglas http://dunglas.fr
[PHP-DEV] Why does checkdnsrr() default to MX??
ANY (*) requests are key to many DNS amplification attacks and may fail, even if the RR you want exists when individually requested. Such requests should be discouraged by clients, IMO. It's disappointing that PHP's dns_get_record() defaults to ANY. But more to the point, what is the client-side utility? You are basically flooding yourself if you make such requests -- what exactly are you going to do with the TXT records, NS records, the SOAs, the unknown types? This is just a ton of extraneous data, even if the overall payload is small. Maybe if you're building a PHP app whose sole purpose is to troubleshoot DNS. But if so I would sooner fork `dig`, since most likely you are trying to show people the results that a non-PHP app would see, so better to avoid any PHP bugs/specialness and miss any DNS features (such as new RR types and new DNS extensions). I don't think there's anything particularly askew in MX being the default for checkdnsrr() if you think of it as a cut-down generalization of getdnsmx(). Still I can't remember the last time my PHP apps cared only about whether an RR existed, not its value (our mail server cares about that of course when checking blacklists, and we care when we're troubleshooting... but not within PHP). And I've *never *wanted to get a true/false *if there is an RR of any type, *as opposed to a true/false if the domain exists at all in the public DNS. Can you explain the use case? -- Sandy
Re: [PHP-DEV] Why does checkdnsrr() default to MX??
On 18 September 2014 21:31:33 GMT+01:00, Sanford Whiteman figureone...@gmail.com wrote: ANY (*) requests are key to many DNS amplification attacks and may fail, even if the RR you want exists when individually requested. Such requests should be discouraged by clients, IMO. It's disappointing that PHP's dns_get_record() defaults to ANY. But more to the point, what is the client-side utility? You are basically flooding yourself if you make such requests -- what exactly are you going to do with the TXT records, NS records, the SOAs, the unknown types? This is just a ton of extraneous data, even if the overall payload is small. Maybe if you're building a PHP app whose sole purpose is to troubleshoot DNS. But if so I would sooner fork `dig`, since most likely you are trying to show people the results that a non-PHP app would see, so better to avoid any PHP bugs/specialness and miss any DNS features (such as new RR types and new DNS extensions). I don't think there's anything particularly askew in MX being the default for checkdnsrr() if you think of it as a cut-down generalization of getdnsmx(). Still I can't remember the last time my PHP apps cared only about whether an RR existed, not its value (our mail server cares about that of course when checking blacklists, and we care when we're troubleshooting... but not within PHP). And I've *never *wanted to get a true/false *if there is an RR of any type, *as opposed to a true/false if the domain exists at all in the public DNS. Can you explain the use case? -- Sandy Hi, I think you might need to take a deep breath, read through the mailing list guidelines [ http://git.php.net/?p=php-src.git;a=blob_plain;f=README.MAILINGLIST_RULES;hb=HEAD], and start again. Your post mentions three different functions, which have different purposes, and different default parameters, and demands that we provide a use case for something (I'm not clear what) because you've never needed it. I would say it is up to you to put forward a considered case for a change, not for everyone else to justify the status quo. What is it you are actually proposing or requesting here? To remove the ability of these functions to query ANY? To remove the default parameter so that people don't use ANY accidentally? Or to change the default value to something different? Bear in mind that any change needs to take into account compatibility with existing code, so removing or changing a default parameter requires a strong justification to offset the problems it may cause users. I hope this message doesn't sound too negative, and look forward to clarification of your thoughts. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why does checkdnsrr() default to MX??
On 18 September 2014 22:19:46 GMT+01:00, Rowan Collins rowan.coll...@gmail.com wrote: I hope this message doesn't sound too negative, and look forward to clarification of your thoughts. Apologies, I've just realised that that message wasn't in fact the beginning of the thread, so some of my comments are way off base. Out of context, it looked like a bit of a rant about how ANY could never be a useful option. Still, the only line that really addressed the question was this: I don't think there's anything askew in MX being the default for checkdnsrr() if you think of it as a cut-down generalization of checkdmsmx() (Sorry, that's not a direct quote because I'm having copy and paste issues.) Sorry again for the misunderstanding. -- Rowan
Re: [PHP-DEV] Why does checkdnsrr() default to MX??
I was just composing an e-mail advising you to follow general netiquette rules and read the original post. :) I disagree utterly that I did not sufficiently address the question. I addressed it in multiple ways: [1] ANY queries create extraneous traffic, so you want fewer PHP functions defaulting to them, not more; [2] ANY queries may fail, giving a false negative, when individual RRs would succeed; [3] An ANY query that only reduces to a *boolean *is a particular waste of energy and network traffic if you're trying to see whether a domain has any records, as you can use SOA for that, with no loss of fidelity; [4] *if* checkdnsrr() is generalized from dns_get_mx() that is another explanation I think [4] is actually my weakest point. -- S. On Thu, Sep 18, 2014 at 5:32 PM, Rowan Collins rowan.coll...@gmail.com wrote: On 18 September 2014 22:19:46 GMT+01:00, Rowan Collins rowan.coll...@gmail.com wrote: I hope this message doesn't sound too negative, and look forward to clarification of your thoughts. Apologies, I've just realised that that message wasn't in fact the beginning of the thread, so some of my comments are way off base. Out of context, it looked like a bit of a rant about how ANY could never be a useful option. Still, the only line that really addressed the question was this: I don't think there's anything askew in MX being the default for checkdnsrr() if you think of it as a cut-down generalization of checkdmsmx() (Sorry, that's not a direct quote because I'm having copy and paste issues.) Sorry again for the misunderstanding. -- Rowan
Re: [PHP-DEV] Why does checkdnsrr() default to MX??
... thought I just top-posted for the first time in, like, ever -- b/c I guess janky Gmail does that by default (I had to switch my subscribed address as php.net was deleting mail relayed through my ISP).
[PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c
Hi Nikita, On Thu, September 18, 2014 22:34, Nikita Popov wrote: On Thu, Sep 18, 2014 at 5:14 PM, Anatol Belski a...@php.net wrote: Commit:e8b497ad8eb74273f7f44ae7e515e7a5e95b50f7 Author:Anatol Belski a...@php.net Thu, 18 Sep 2014 16:45:50 +0200 Parents: f162b3f736f07ad868abec6ea8b44a91e77d4069 Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=e8b497ad8eb74273f7f44ae 7e515e7a5e95b50f7 Log: fix CG(empty_string) init in ZTS Changed paths: M Zend/zend.c Diff: diff --git a/Zend/zend.c b/Zend/zend.c index 46719b4..6a53179 100644 --- a/Zend/zend.c +++ b/Zend/zend.c @@ -120,6 +120,7 @@ static HashTable *global_class_table = NULL; static HashTable *global_constants_table = NULL; static HashTable *global_auto_globals_table = NULL; static HashTable *global_persistent_list = NULL; +static zend_string *default_empty_string = NULL; #endif ZEND_API zend_utility_values zend_uv; @@ -514,6 +515,15 @@ static void compiler_globals_ctor(zend_compiler_globals *compiler_globals TSRMLS compiler_globals-static_members_table = NULL; } compiler_globals-script_encoding_list = NULL; + +#ifdef ZTS + compiler_globals-empty_string = zend_string_alloc(sizeof()-1, 1); + compiler_globals-empty_string-val[0] = '\000'; + zend_string_hash_val(compiler_globals-empty_string); + compiler_globals-empty_string-gc.u.v.flags |= IS_STR_INTERNED; + + memset(compiler_globals-one_char_string, 0, sizeof(compiler_globals-one_char_string)); +#endif } /* }}} */ @@ -538,6 +548,10 @@ static void compiler_globals_dtor(zend_compiler_globals *compiler_globals TSRMLS pefree((char*)compiler_globals-script_encoding_list, 1); } compiler_globals-last_static_member = 0; + +#ifdef ZTS + free(compiler_globals-empty_string); +#endif } /* }}} */ What does this fix and how does it relate to the initialization done in zend_interned_strings_init? Btw, does anyone know why we don't use interned strings in ZTS? Nikita So CG in a new thread is first a virgin chunk of memory. zend_interned_strings_init() allocates CG(empty_string) in the master thread first. In contrary to NTS, where the request is processed using the same globals, the TS model will need to initialize all the globals for everythread. Every structure in a thread is malloc'd and then it's members go through the corresponding ctor routines (compiler_globals_ctor in this case). However the init in TS happens once per thread, not per request. The flow in TS, very rough vision startup (init globals, master) start thread 0 (init globals, thread 0) serve request 0 serve request 1 .. serve request n shutdown thread 0 (free globals, thread 0) .. start thread n (init globals, thread n) serve request 0 serve request 1 .. serve request n shutdown thread n (free globals, thread n) shutdown (free globals, master) As one can see, the globals between threads are different and have to be initialized separately. For every thread, it copies the data skeleton from the master thread, but the thread ueses them on it's own then. Why don't we use interned strings in TS - good question. After a day of debugging I'd say it were a challenge to fix some crazy bugs if one decides to do that :) Either it would need to work by the same flow as globals, say one pool per thread (which is kinda wasteful), or one would go the right way and share the pool between threads, but then having to handle all the concurrency issues. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why does checkdnsrr() default to MX??
On 18 September 2014 22:47:36 GMT+01:00, Sanford Whiteman figureone...@gmail.com wrote: I was just composing an e-mail advising you to follow general netiquette rules and read the original post. :) Yeah, for some reason your first message shows up as a standalone post, with no hint that it was a reply, so I completely missed the context. :/ I disagree utterly that I did not sufficiently address the question. Fair enough. I'll let others take up the conversation, before I dig myself in any deeper. Personally, I've never used *any* DNS functionality from PHP, so the whole thing is rather academic to me. Apologies again for any offence. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL
On 18 Sep 2014, at 21:26, Kévin Dunglas dung...@gmail.com wrote: I'm working on enhancing the FILTER_VALIDATE_URL filter ( https://github.com/php/php-src/pull/826). The current implementation does not support validation of internationalized domain names (i.e: http://www.académie-française.fr/ http://www.xn--acadmie-franaise-npb1a.fr/). Support of IDN validation can be easily added using ICU's uidna_toASCII() function. Is it acceptable to add a dependency to ICU for ext/filter? Another option is to add a HAVE_ICU constant in main/php_config.h and to validate IDN only if ICU is present. What strategy is preferred? Perhaps add a new filter that covers normal URLs and IDN ones? I just imagine it might cause problems if suddenly IDNs are accepted, if there is a backend which can’t handle them. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL
On 19 Sep 2014, at 06:52, Andrea Faulds a...@ajf.me wrote: On 18 Sep 2014, at 21:26, Kévin Dunglas dung...@gmail.com wrote: I'm working on enhancing the FILTER_VALIDATE_URL filter ( https://github.com/php/php-src/pull/826). The current implementation does not support validation of internationalized domain names (i.e: http://www.académie-française.fr/ http://www.xn--acadmie-franaise-npb1a.fr/). Support of IDN validation can be easily added using ICU's uidna_toASCII() function. Is it acceptable to add a dependency to ICU for ext/filter? Another option is to add a HAVE_ICU constant in main/php_config.h and to validate IDN only if ICU is present. What strategy is preferred? Perhaps add a new filter that covers normal URLs and IDN ones? I just imagine it might cause problems if suddenly IDNs are accepted, if there is a backend which can’t handle them. We don’t need a new filter, you can simply add a filter flag for FILTER_VALIDATE_URL, e.g. FILTER_FLAG_ALLOW_IDN. Of course, the ICU dependency should be optional :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.33 Released
Hello! The PHP development team announces the immediate availability of PHP 5.4.33. 10 bugs were fixed in this release. All PHP 5.4 users are encouraged to upgrade to this version. This release is the last planned release that contains regular bugfixes. All the consequent releases will contain only security-relevant fixes, for the term of one year. PHP 5.4 users that need further bugfixes are encouraged to upgrade to PHP 5.6 or PHP 5.5. For source downloads of PHP 5.4.33 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes are recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.4.33 Stanislav Malyshev PHP 5.4 RM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Internationalized Domain Name support in FILTER_VALIDATE_URL
Hi, The flag is a good idea to handle old systems but the feature must be enabled by default (at least for PHP 7) and disablable through the flag. IDN RFCs are more than 10 years old. All major browsers and registrars support IDN. Le vendredi 19 septembre 2014, Tjerk Meesters tjerk.meest...@gmail.com a écrit : On 19 Sep 2014, at 06:52, Andrea Faulds a...@ajf.me javascript:; wrote: On 18 Sep 2014, at 21:26, Kévin Dunglas dung...@gmail.com javascript:; wrote: I'm working on enhancing the FILTER_VALIDATE_URL filter ( https://github.com/php/php-src/pull/826). The current implementation does not support validation of internationalized domain names (i.e: http://www.académie-française.fr/ http://www.xn--acadmie-franaise-npb1a.fr/ http://www.xn--acadmie-franaise-npb1a.fr/). Support of IDN validation can be easily added using ICU's uidna_toASCII() function. Is it acceptable to add a dependency to ICU for ext/filter? Another option is to add a HAVE_ICU constant in main/php_config.h and to validate IDN only if ICU is present. What strategy is preferred? Perhaps add a new filter that covers normal URLs and IDN ones? I just imagine it might cause problems if suddenly IDNs are accepted, if there is a backend which can’t handle them. We don’t need a new filter, you can simply add a filter flag for FILTER_VALIDATE_URL, e.g. FILTER_FLAG_ALLOW_IDN. Of course, the ICU dependency should be optional :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20
[PHP-DEV] Re: Internationalized Domain Name support in FILTER_VALIDATE_URL
On Fri, Sep 19, 2014 at 1:24 PM, Kévin Dunglas dung...@gmail.com wrote: Hi, The flag is a good idea to handle old systems but the feature must be enabled by default (at least for PHP 7) and disablable through the flag. IDN RFCs are more than 10 years old. All major browsers and registrars support IDN. My apologies, I meant the inverse. If ICU is enabled we should make FILTER_VALIDATE_URL check IDN by default and add a flag to allow malformed IDN. However, it should not enforce the dependency on ICU itself; if it's there, it will be used, otherwise it will allow malformed IDN by default (if present). Personally I wouldn't mind having this for 5.6 as well if the upgrade path is clean, but the cleanest path I could think of involves having two flags that do the opposite action :) Le vendredi 19 septembre 2014, Tjerk Meesters tjerk.meest...@gmail.com a écrit : On 19 Sep 2014, at 06:52, Andrea Faulds a...@ajf.me wrote: On 18 Sep 2014, at 21:26, Kévin Dunglas dung...@gmail.com wrote: I'm working on enhancing the FILTER_VALIDATE_URL filter ( https://github.com/php/php-src/pull/826). The current implementation does not support validation of internationalized domain names (i.e: http://www.académie-française.fr/ http://www.xn--acadmie-franaise-npb1a.fr/ http://www.xn--acadmie-franaise-npb1a.fr/). Support of IDN validation can be easily added using ICU's uidna_toASCII() function. Is it acceptable to add a dependency to ICU for ext/filter? Another option is to add a HAVE_ICU constant in main/php_config.h and to validate IDN only if ICU is present. What strategy is preferred? Perhaps add a new filter that covers normal URLs and IDN ones? I just imagine it might cause problems if suddenly IDNs are accepted, if there is a backend which can’t handle them. We don’t need a new filter, you can simply add a filter flag for FILTER_VALIDATE_URL, e.g. FILTER_FLAG_ALLOW_IDN. Of course, the ICU dependency should be optional :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20 -- -- Tjerk
