What did PHP's y2k_compliance php.ini setting do?
Asked Answered
H

2

5

This question is purely for academic purposes, as the setting was removed in PHP 5.4 and the year 2000 is long past, but does anyone know what the y2k-compliance configration setting did?

The PHP documentation doesn't tell you much:

y2k_compliance (boolean)

Enforce year 2000 compliance (will cause problems with non-compliant browsers)

So, not much useful information there!

From a Google search, which mostly turned up repeats of the above or references to the setting's removal, the only additional information I found was this page, which states:

Some users may be using wildly outdated, noncompliant browsers. If for some bizarre reason you're sure that a number of your site's users fall into this group, then disable the y2k_compliance parameter; otherwise, it should be enabled.

y2k_compliance = On

Specifies whether or not the PHP script should be made year-2000 compliant. Making the PHP script Y2K compliant (by setting this directive to On) will cause problems with non-Y2K-compliant browsers.

A bit more information, but still a very high-level description.

I have been unable to find any technical information about what problem this setting was trying to solve or how it went about solving it.

So, what did PHP do differently if the y2k-compliance flag was disabled?

Hypabyssal answered 10/8, 2019 at 20:45 Comment(5)
This question has received two great answers, and I don't really know how to decide which one to accept, and I can't accept both! How do I decide? Pick the one which was posted earlier? Pick neither? Write my own answer which synthesises them both (seems a bit pointless - it wouldn't add anything)? Toss a coin?Hypabyssal
Just pick any answer you wish to reward the credit to. Either way, future users will know that the question was resolvable and the other answers will still be available for additional insight. It usually not common to see people take other answers and consolidate them into a new one unless they are providing some additional value or insight. It is, however, a good idea to at least mark something as answer if your question was resolved.Retardation
I picked Sebastian's answer, as it had more votes, but really there was very little to choose between them.Hypabyssal
I understand your position, and it is made even more difficult because both answers complement each other. I do believe that if somebody does land on this question again they'll end up reading both, however.Fernery
...and now they both have the same number of votes! :-) If I could split the points, I would, but there you go.Hypabyssal
R
5

Well, isn't that a blast from the past! I haven't seen this one for at least 10 years.

The behaviour is simple and actually easily trackable back to the source code. It only really affects one part of the PHP engine.

The crux of it is simple. RFC 850 (1983) specified that all date formats should have the last two digits of the date. RFC 822 changed this. However, this didn't mean that all browsers magically updated or even knew how to handle this.

For this reason, this flag was added, so people could set at will whether they wanted the old format, or the new one, based on how many users they had running old (at the time) browsers.

Ragged answered 10/8, 2019 at 21:3 Comment(2)
Interesting that this was a simple on/off switch based on your expected user-base, rather than something that was handled by browser sniffing. You'd have thought that would be a more robust approach. I suppose you could implement your own browser-sniffing though, and set the flag accordingly.Hypabyssal
@Hypabyssal this was the sort-of-early days of the internet. To give you an idea of how this happened, the RFC that "codified", or at least set in motion the user-agent header is tools.ietf.org/html/rfc1945#page-46 from 1996, further codified by tools.ietf.org/html/rfc2616#page-145 (The HTTP/1.1 RFC) in 1999. The parameter rolled into PHP in 2001, so this was cutting edge and a band-aid fix for navigators that didn't support what the RFCs outlined.Fernery
R
3

Not sure if this helps, but I found some old documentation from PHP3 that describes Y2K Compliance in a little more detail. As expected, it has to do with handling 2-digit year formatting.

Source: archive.org:php.net/y2k.php3

Year 2000 Compliance and PHP

Like Perl, PHP is about as Year 2000 compliant as your pencil. It is the applications you write with PHP you need to worry about, not PHP itself.

There is an issue with the dates in cookies. Netscape originally specified that the expiry date on a cookie should be in a 2-digit year format. Due to all the y2k hype, they decided to change this behaviour in Netscape 4 and up. This doesn't mean that the 2-digit year is not y2k compliant. A 2-digit year of "13", for example will be understood as the year 2013 in Netscape. All browsers understand this 2-digit format, and thus this is the default in PHP. Some y2k fanatics still insist on never using a 2-digit year no matter what, and for those people PHP has a y2k_compliance configuration setting available in the php3.ini file.

Retardation answered 10/8, 2019 at 21:1 Comment(3)
That's a strangely unenlightened view point, considering it was written by technologists. To be dismissing a very real technical issue as the viewpoint of 'fanatics' and in the same sentence to completely demonstrate why 2-digit years are a problem ("understood as the year 2013 in Netscape" - but what about other browsers?). I think it demonstrates the naivety of the PHP team at that point in history. Glad they had grown up a bit by the time PHP4 came along, where this flag became enabled by default! :-)Hypabyssal
That's still one more browser than just Netscape. :-) Either way, it still shows a lack of understanding of the point of standardisation and about what it means to be y2k compliant.Hypabyssal
Yeah, still, though...Netscape was like 80+% market share in the mid-to-late 90s and the issue they were solving with this setting was more to deal with that one client browser (deservedly so) instead of server-side issues. I think its safe to go easy on them for for this 20 year old documentation of the early years of PHP.Retardation

© 2022 - 2024 — McMap. All rights reserved.