W3C's planned transition to HTTPS stymied by legacy laggards
- Reference: 1661209208
- News link: https://www.theregister.co.uk/2022/08/22/w3cs_transition_https/
- Source link:
The organization, which gets hundreds of millions of requests per day to its website, had delayed that transition for fear of breaking legacy web applications, many of which rely on resources reached via HTTP. But it now says it's nearly good to go, at some point.
"The primary reason for this is that we wanted to avoid causing issues for [1]software requesting machine-readable resources from www.w3.org such as HTML DTDs, XML Schemas, and namespace documents," explained W3C sysadmin Gerald Oskoboiny in [2]a post on July 25.
[3]
"We believe enough time has passed for most such software to have been updated to handle redirects and https, so we are planning to start redirecting all requests received over http to https within a month or two."
[4]
[5]
That target date, set one month ago, became indeterminate on Monday when Oskoboiny published [6]a follow-up blog post for the W3C outlining learnings from the initial tests of the HTTP-to-HTTPS tests.
About two hours prior, The Register had inquired about the transition plan due to concerns raised by a reader. We're told that the W3C blog update was planned and unrelated to our inquiry.
[7]
"There is no firm date; the rollout will be informed by our tests and the feedback we receive," said Oskoboiny in an email to The Register on Monday.
Refreshing Java not their cup of tea
The reader who works for a major communications provider wrote to The Register over the weekend to question the proposed timeline. This individual, who asked not to be named because he does not have his employer's authorization to speak to the press, said he has to support a large Java-based web app that's about two decades old.
Updating large Java apps to HTTPS, he said, looks likely to prove costly because the code will need to be changed and tested. And he believes the majority of sysadmins won't be ready for the impact that the HTTPS switchover has on production systems that depend on externally hosted W3C resources. The implicated XML schemas, he suggested, are often used in government applications for inter-department, machine-to-machine communications.
Preliminary testing has been turbulent. Two initial tests of the HTTP-to-HTTPS redirection, for eight hours starting August 1 and for just over 27 hours starting August 18, prompted multiple reports of application failures. In fact, the second test had been scheduled for 72 hours but was cut short "due to several complaints that this change was impacting production services," explained Oskoboiny.
Those affected by the trial HTTP-to-HTTPS redirection said the changeover broke code intended to validate XML schemas, an optional but highly advisable step to ensure that XML data is properly formed. Builds for Microsoft's [8]Static Driver Verifier tool, which verifies the source code of Windows kernel-mode drivers, also failed, according to one commenter.
[9]
"During our initial tests we heard from a few people that this was causing issues with their systems that make automated requests to our site, for example when doing XML Schema validation," said Oskoboiny in Monday's post. "We are hoping these systems can be reworked to either follow the redirects to https, or use an XML catalog to keep local copies of any files needed to avoid making unnecessary requests to our site."
[10]W3C overrules objections by Google, Mozilla to decentralized identifier spec
[11]Mozilla edict: 'Web-accessible' features need 'secure contexts'
[12]What if Chrome broke features of the web and Google forgot to tell anyone? Oh wait, that's exactly what happened
[13]Makers of ad blockers and browser privacy extensions fear the end is near
Some of the applications cited by commenters use Java components like the javax.xml.validation package in JDK 11 or javax.xml.validation.SchemaFactory in JDK 8.
These components in turn rely on software like [14]Apache Xerces , an open source collection of tools for handling XML that's used widely in Java, or [15]libxml2 , an open source software library for XML parsing.
In the case of libxml2, an issue was opened two years ago to ask for HTTPS support. A year ago, project maintainer Nick Wellnhofer rebuffed a request to add https, [16]saying that the library doesn't do so because "it's a bad idea to load resources over the network for performance and availability reasons."
Oskoboiny echoed that sentiment. "It's good to be aware of any dependencies you might have on third-party sites," he told The Register .
"It's surprising that modern software that makes HTTP requests wouldn't have the ability to handle redirects or https. Please make sure your software is up to date, and report issues to the developers if needed."
Three days ago, developer Karl Brown joined the discussion to ask Wellnhofer to reconsider in light of the W3C's deprecation of HTTP support. "This is going to break a lot of tools that rely on libxml2 (such as lxml)," Brown's [17]post says. "While I agree schema validation over the internet is not efficient, it is likely widely used and the work-arounds are kludgy."
In order for that to happen, Wellnhofer responded, someone would need to step forward to implement the feature and support it in the years to come. Welcome to open source development.
The next test is scheduled to run for 48 hours, from 1700 UTC [18]on Sep 1 until 1700 UTC Sep 3 The sign to fasten your seatbelt is now illuminated. ®
Get our [19]Tech Resources
[1] https://www.w3.org/blog/2008/02/w3c_s_excessive_dtd_traffic/
[2] https://www.w3.org/blog/2022/07/redirecting-to-https-on-www-w3-org/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.w3.org/blog/2022/08/https-redirection-observations/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/static-driver-verifier
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2022/07/01/w3c_overrules_objections/
[11] https://www.theregister.com/2018/01/18/mozilla_secure_contexts_edict/
[12] https://www.theregister.com/2021/10/04/chrome_breaks_web/
[13] https://www.theregister.com/2022/06/08/google_blocking_privacy_manifest/
[14] https://xerces.apache.org/
[15] https://gitlab.gnome.org/GNOME/libxml2/-/wikis/home
[16] https://gitlab.gnome.org/GNOME/libxml2/-/issues/160#note_1005174
[17] https://gitlab.gnome.org/GNOME/libxml2/-/issues/160#note_1532589
[18] https://status.w3.org/
[19] https://whitepapers.theregister.com/
Re: Wellnhofer is incoherent
Some points.
1. Are you offering to write and maintain the HTTPS support, as suggested by Wellnhofer? If no, then why complain?
2. If you followed the link and read it, you would see a couple of points. Wellnhofer wrote a year ago that "adding HTTP support directly to the library was a mistake". And six months ago he wrote "I'll probably start by disabling HTTP and FTP support by default.".
He is far from being incoherent. He has made his position clear. You can always fork the code and provide your own solution instead of lobbing in uninformed insults.
appeal to incompetence
Tech A "you should update that." Maintainer, "you're right". Tech B "That broke my deployment" Maintainer "Fix your shit" Tech B "NO"
Maintainer to tech A "Sorry, you can't have nice things because that guy is an idiot."
The lazy ones already hacked together something with SQUID. The smart ones are either also lazy or unwilling to do a strict validation test over an unvalidateable connection.
Corollary: We are all using the part of the Internet built for the dumbest half of the web developers. That's the whole internet. No other part exists.
Critical component "A" REQUIRES JDK 8.
Without critical component "A", none of us have jobs and the owners get sued for failing to deliver.
Higher level JDKs are NOT an option at this time, and even the NEWER versions of that component require JDK 11 as their portability base, so they will NOT be using newer functionality.
Only because after JDK 8, there is a license cost to users associated with using Java.
Wellnhofer is incoherent
If his concern is about loading schemas over the network, he should disable unencrypted HTTP as well.