PHP 5.6.0

Byla vydána nová verze PHP 5.6.0. Vedle oprav chyb mezi klíčové vlastnosti nové verze patří např. podpora pro nahrávání souborů větších než 2 GB, integrace debuggeru phpdbg, objevují se konstantní skalární výrazy nebo variadické funkce s proměnným počtem parametrů. Více v seznamu změn.

31.8.2014 13:39 | MMMMMMMMM | Nová verze

Komentáře

[Josef Kufner]

Zdá se, že už máme zárodek přetěžování operátorů. Jsem zvědav, za jak dlouho se objeví magické metody __add, __sub a podobné.

[Šangala]

podpora pro nahrávání souborů větších než 2 GB

a tedy

Uploads equal or greater than 2GB in size are now accepted.

jsem nějak nepobral, to se vztahuje k čemu, jsem přesvědčený, že na 64bit systému, nastaveném PHP a nastaveném Apache jsem větší soubory než 2GB už upload-oval na výrazně nižší verzi…, to se mi jen zdálo(?)

[Conscript89]

Mozna jde prave o 32bit build.

[MMMMMMMMM]

Na základě tohoto příspěvku jsem se díval do zdrojáku PHP 5.5.16 a 5.3.29 do souboru main/SAPI.h, kde je proměnná read_post_bytes deklarována jako int, přičemž v PHP 5.6.0 je jako int64_t, takže by to teoreticky v žádné předchozí verzi bez příslušného patche nemělo fungovat? Já to nikdy nepoužil, nemohu referovat...

[Šangala]

Příloha:

• kuk.php (1191 bytů)

Tak jsem to zkusil normálně to lze, z přiloženého (copy&paste slátaného) dostanu výstup:

Setting

Version: 5.3.3-7+squeeze21
upload_max_filesize: -1
post_max_size: 4800M

Info $_FILES['file']

Upload: bigfile_4.5GiB
Type: application/octet-stream
Size: 512 MiB
Stored in: /tmp/phpuxpGLo

Filesize(): 4608 MiB

fstat()

Array
(
    [dev] => 64768
    [ino] => 34020
    [mode] => 33152
    [nlink] => 1
    [uid] => 33
    [gid] => 33
    [rdev] => 0
    [size] => 4831838208
    [atime] => 1409516093
    [mtime] => 1409516234
    [ctime] => 1409516234
    [blksize] => 4096
    [blocks] => 9446424
)

size: 4608 MiB

Prostě to normálně šlo i dřív, ale nebylo to (asi) možné limitovat pomocí upload_max_filesize (však stačí post_max_size) a přetáčelo to „tachometr“ v poli $_FILES.

[Jendа]

Kolik má ten stroj paměti? Resp. už to v defaultu nahrává na disk a ne do RAM?

[Šangala]

4GiB, tímto způsobem to leze do tmp filesu, jaký buffer to používá nevím, ale řekl bych, že to není poznat na využití paměti.

[Max]

Nevím, ale není tato fce stejně tak nějak irelevantní? Dnes se na uploadování používají různé uploadery, což je komplexní řešení s čárou života, podporou přerušovaného uploadování, drag and drop a hafo dalších fcí a nic je nelimituje.
Zdar Max

[Šangala]

No ano, ale pokud je server PHP, tak se stejně napícháváš na PHP.

[Max]

Tak to samozřejmě, to nevyvracím. Já jen říkám, že toto je už dávno relativně dobře pořešeno.
Zdar Max

[Šangala]

Napadá mně, že existují doprovodná řešení v PHP jako web access na sFTP a nejsnazší je to řešit tak, že v případě uploadu se soubor uploaduje na https server a pak klasickým ftp přenosem (na localhostu, nebo v interní síti) se to přenese na FTP úložiště (řeší to jednotná práva a přihlašovací údaje, založená jen na FTP účtech).

Znám minimálně dvě řešení, které to tak mají a co jsem viděl tak se i používají - nahrávat sice takto 2GiB+ není asi to nejlepší, ale jako občasné/záložní řešení pro BFU to lze použít - no a proč být limitovaný na 2GiB, když třeba limit přes sFTP je např. 32GiB.

Prostě je dobře, že konečně ten bordel s 2^31 v PHP jak v načítání konfiguračních voleb (s atoi() ) apod. konečně nějak řeší. 32bit OS(, který se stále na něco hodí lépe než 64bit) nemusí být limitovaný v roce 2014 jen na 2^31 soubory.

[Jendа]

Za mých mladých let hlavně Apache celý nahrávaný soubor nejdřív nahrál do RAM a až pak ho flushnul na disk. Ale možná to bylo blbě nastavené.

[sigma]

Taky možná záleží jestli byl použit mod_php nebo CGI/FastCGI. Ve FastCGI módu to snad nedělal nikdy, tam je jen malý buffer a PHP procesu se celý request předává přes stdin. Je možné, že nějaká historická verze PHP i v tomto případě celý request nahrávala do paměti, ale moc se mi to nezdá...

[Hermetus]

kdo je trouba a nevy to tak pristi major verze nebude 6 ale 7