Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123595
Precedence: bulk
MIME-Version: 1.0
References: <CAPyeZ4O2rK+2ApuE-YLc7j_Z2LcT29yHcLYXvB0oGs-D_zTSag@mail.gmail.com>
In-Reply-To: <CAPyeZ4O2rK+2ApuE-YLc7j_Z2LcT29yHcLYXvB0oGs-D_zTSag@mail.gmail.com>
Date: Thu, 13 Jun 2024 20:48:19 +0100
Message-ID: <CAMjSS5OPKm0dRP+ckCdpBd4Kg1aRhU5QgcuTWwPTnyC_1aZRkw@mail.gmail.com>
Subject: Re: [PHP-DEV] Revisiting case-sensitivity in PHP
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000020e12061acaca3d"
From: ttijhof@wikimedia.org (Timo Tijhof)

--000000000000020e12061acaca3d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Would this affect unserialize()?

I ask because MediaWiki's main "text" database table is an
immutable/append-only store where we store the text of each page revision
since ~2004. It is stored as serialised blobs of a value class. There have
been a number of different implementations over the past twenty years of
Wikipedia's existence (plain text, gzip-compressed, diff-compressed, etc.).

When we adopted modern autoloading in MediaWiki, we quickly found that
blobs originally serialized by PHP 4 actually encoded the class in
lowercase, regardless of the casing in source code.

From https://3v4l.org/jl0et:

> class ConcatenatedGzipHistoryBlob {=E2=80=A6}
> print serialize($blob);
> # PHP 4.x: O:27:"concatenatedgziphistoryblob":=E2=80=A6
> # PHP 5/7/8: O:27:"ConcatenatedGzipHistoryBlob":=E2=80=A6


It is of course the application's responsibility to load these classes,
but, it is arguably PHP's responsiblity to be able to construct what it
serialized. I suppose anything is possible when announced as a breaking
change for PHP 9.0. I wanted to share this as something to take into
consideration as part of the impact. Potentially worthy of additional
communicating, or perhaps worth supporting separately.

--
Timo Tijhof,
Principal Engineer,
Wikimedia Foundation.
https://timotijhof.net/

--000000000000020e12061acaca3d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Would this affect unserialize()?<br></div><div><br></=
div><div>I ask because MediaWiki&#39;s main &quot;text&quot; database table=
 is an immutable/append-only store where we store the text of each page rev=
ision since ~2004. It is stored as serialised blobs of a value class. There=
 have been a number of different implementations over the past twenty years=
 of Wikipedia&#39;s existence (plain text, gzip-compressed, diff-compressed=
, etc.).<br></div><div><br></div><div>When we adopted modern autoloading in=
 MediaWiki, we quickly found that blobs originally serialized by PHP 4 actu=
ally encoded the class in lowercase, regardless of the casing in source cod=
e.<br></div><div><br></div><div>From <a href=3D"https://3v4l.org/jl0et">htt=
ps://3v4l.org/jl0et</a>:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">class ConcatenatedGzipHistoryBlob {=E2=80=A6}<br>print serialize=
($blob);<br># PHP 4.x: O:27:&quot;concatenatedgziphistoryblob&quot;:=E2=80=
=A6<br># PHP 5/7/8: O:27:&quot;ConcatenatedGzipHistoryBlob&quot;:=E2=80=A6<=
/blockquote><div><div><br></div><div>It is of course the application&#39;s =
responsibility to load these classes, but, it is arguably PHP&#39;s respons=
iblity to be able to construct what it serialized. I suppose anything is po=
ssible when announced as a breaking change for PHP 9.0. I wanted to share t=
his as something to take into consideration as part of the impact. Potentia=
lly worthy of additional communicating, or perhaps worth supporting separat=
ely.<br></div><div><br></div><div>--<br></div><div>Timo Tijhof,<br></div><d=
iv>Principal Engineer,<br></div><div>Wikimedia Foundation.<br></div><div><a=
 href=3D"https://timotijhof.net/">https://timotijhof.net/</a></div><div><br=
></div></div></div>

--000000000000020e12061acaca3d--