Re: [PHP-DEV] Adding new MIME types for the CLI web server
On 31/10/13 21:32, Derick Rethans wrote: Isn't there a reason why you can't use the fileinfo extension/code for this instead? Hardcoding it seems rather strange? I looked at the manual and mime_content_type() is deprecated and tells me to use the Fileinfo PECL extension. From which I am led back to the parent section, which is for the built-in Fileinfo extension. Looks like the manual is out-of-date. Anyhow, looks like finfo_file() works as we'd want, though I feel uneasy about guessing filetypes this way. Perhaps we should have several explicitly specified ones (.txt as text/plain, .html as text/html, etc.), and guess the rest? Especially for ones which it would not correctly guess. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Use default_charset As Default Character Encoding
On 10/31/2013 09:21 AM, Yasuo Ohgaki wrote:
Hi Joe,
On Thu, Oct 31, 2013 at 6:07 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Thu, Oct 31, 2013 at 5:31 PM, Joe Watkins krak...@php.net wrote:
How could you override them ??
It's in PoC patch.
I made it while 5.5 was in beta, but it would work.
If they are removed then they cannot be referenced.
If they are not being removed then nothing is being simplified ...
The most important objective is when you are using 'UTF-8' (I guess it's
standard today)
All you should do is
default_charset='UTF-8'
then PHP uses the setting anywhere it can apply. (e.g. htmlspecialchars,
mbstring functions, etc)
I have to work on functions, but php.ini related staff is in PoC patch.
I forgot to mention that it helps i18n applications also.
For example, preg and sqlite only accepts UTF-8 as MBCS char. Users may
write
if (ini_get('default_charset') !== 'UTF-8') {
$str = mb_convert_encoding($str, 'UTF-8');
}
preg, sqlite function calls here.
It simplifies things for sure.
I'll add these in RFC later.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Sorry, I'm a shit. I should have looked at the patch first before
opening my big gob.
I will look at the patch, and join in when I have a clue :)
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: Expectations
On 10/18/2013 10:46 PM, Joe Watkins wrote: Evening Chaps, Following on from discussion regarding assertion API in PHP, the following RFC is now up for discussion: https://wiki.php.net/rfc/expectations Please do point out any missing sections or information, so that it can be clarified as quickly as possible. I hope this conveys the idea a bit clearer to everyone ? Cheers Joe Evening, Wanted to bring this up for vote, any objections ? Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding new MIME types for the CLI web server
Hi! Final comments anyone, before I commit next week? It looks strange that we have to hardcode so many mimetypes in the code, and doesn't sound a scalable solution. Can't we make it use data from fileinfo or some other customizeable table so we don't have to keep all MIME types hardcoded in the code? Maybe some ability to use Apache's mime.types file? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cleanup of old remote branches
On 2013-10-30 21:15, Yasuo Ohgaki wrote: Hi all, On Thu, Oct 31, 2013 at 1:58 AM, Adam Harvey ahar...@php.net wrote: On 29 October 2013 03:56, Julien Pauli jpa...@php.net wrote: Could we make a list of the remote branches we really don't need anymore, and clean them up ? Also -1 here. Command line tab completion and GitHub's branch filtering UI basically make the cognitive overhead of dealing with this minimal, and having a full history is important. Unfortunately, we already lost important source code history in our git. Checkout PHP 4.X branches, then you'll see there aren't any Zend dirs. If we should keep current git data, how about create repository called git-lagacy.php.net? (And add missing Zend dirs for older PHP in there) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net +1 for this idea. We need the history but the brances should be cleaned up. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Use default_charset As Default Character Encoding
On 10/31/2013 08:28 AM, Martin Keckeis wrote: I don't see that it is possible to merge the settings from different libraries, what if an application is relying on mbstring and iconv having different settings ?? I think this use case is descibed in the RFC. The default_charset can be overwritten: default_charset php.* mbstring.*/iconv.* encoding specified by functions It's possible that applications are relying on the separation of their settings in order to function properly, is what I am trying to say. The same like above. The only way you could possibly merge those configuration settings is by also merging the functionality, there's no backward compatible way to do that, but I can imagine at some time in the future those libraries being used to support all of the required input/output/script encoding features at the level of Zend. I don't see how this can move forward and not break stuff ... I think it's the same like above...You can override the default setting, so everything should be fine. I'm +1 for this, as there are really to much unnecessary settings around! How could you override them ?? If they are removed then they cannot be referenced. If they are not being removed then nothing is being simplified ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding new MIME types for the CLI web server
On Thu, 31 Oct 2013, Christopher Jones wrote:
The PHP CLI web server 5.5 currrently supports these MIME types
natively:
{ html, text/html },
{ htm, text/html },
{ js, text/javascript },
{ css, text/css },
{ gif, image/gif },
{ jpg, image/jpeg },
{ jpeg, image/jpeg },
{ jpe, image/jpeg },
{ png, image/png },
{ svg, image/svg+xml },
{ txt, text/plain },
{ webm, video/webm },
{ ogv, video/ogg },
{ ogg, audio/ogg },
Final comments anyone, before I commit next week?
Isn't there a reason why you can't use the fileinfo extension/code for
this instead? Hardcoding it seems rather strange?
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding new MIME types for the CLI web server
On 10/31/13 4:12 PM, Stas Malyshev wrote: Hi! Final comments anyone, before I commit next week? It looks strange that we have to hardcode so many mimetypes in the code, and doesn't sound a scalable solution. Can't we make it use data from fileinfo or some other customizeable table so we don't have to keep all MIME types hardcoded in the code? Maybe some ability to use Apache's mime.types file? It isn't scalable, but users can always use a router script to add additional types so there isn't a real world problem in missing uncommon extensions. My idea was to add common extensions to the existing look-up list. A quick and straight-forward solution to making the CLI web-server handle the 80-20 rule. If someone (ajf?) wants to work on a more comprehensive solution instead, I have no objection. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
