W3C's planned transition to HTTPS stymied by legacy laggards

Timing for plan to redirect HTTP requests now indeterminate to allow for further feedback

More than a decade after implementing support for secure HTTPS connections on its website, the World Wide Web Consortium (W3C) is finally planning to begin redirecting insecure HTTP connections to the more protected spec.

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 software requesting machine-readable resources from www.w3.org such as HTML DTDs, XML Schemas, and namespace documents," explained W3C sysadmin Gerald Oskoboiny in a post on July 25.

"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."

That target date, set one month ago, became indeterminate on Monday when Oskoboiny published 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.

"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.

"[The] blog post was inspired in part by your inquiry, but our plans and the timeline for deployment were not. We realized late last week that our initial timeline was likely too optimistic," he later explained.

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 Static Driver Verifier tool, which verifies the source code of Windows kernel-mode drivers, also failed, according to one commenter.

"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."

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 Apache Xerces, an open source collection of tools for handling XML that's used widely in Java, or 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, 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 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 on Sep 1 until 1700 UTC Sep 3 The sign to fasten your seatbelt is now illuminated. ®