SoylentNews is people
SoylentNews
The USPTO (Patent and Trademark Office) has updated its Public Patent Application Information Retrieval (Public-PAIR) service so that it no longer supports HTTPS (secure) access. From the announcement with emphasis added:
Public PAIR Maintenance and Outage
The USPTO will be performing maintenance on the Public Patent Application Information Retrieval (Public Pair) beginning at 12:01 a.m., Friday, April 21 and ending at 2 a.m., Friday, April 21 ET.
During the maintenance period, Public PAIR will be unavailable.
Immediately after the maintenance, users will only be able to access Public PAIR through URLs beginning with HTTP, such as http://portal.uspto.gov/pair/PublicPair. Past URLs using HTTPS to access Public Pair, such as https://portal.uspto.gov/pair/PublicPair, will no longer work.
Can anyone explain why there would be this seemingly backwards move to insecure communications?
(Score: 4, Interesting) by VLM on Monday April 24 2017, @12:06PM
Isn't this questionable news such that the maintenance on publicPAIR is named "Systems Maintenance 1" on apr 20 and its not been mentioned that "Systems Maintenance 2" is scheduled on may 7?
My first guess was we're looking at the https proxy dance where they're either ripping out a https proxy in front of a native http only server and reconfiguring to a native http and https server, or the exact opposite where for whatever front end mumbo jumbo they're ripping out a native http and https server and converting to pure http with a https proxy frontend.
Say you got a load balanced cluster of virtual http-only hosts. Then there's a demand to implement https access. OK fine provision a whopping one single https host that does nothing but proxy incoming https into http. Then over time the https traffic increases and you provision more and more servers. But this architecture is a modest PITA for a variety of reasons, so eventually you want to implement dual protocol http and https on the same front ends, or maybe run the web app on the https servers primarily and have http proxied in. Well depending how cheapskate your cloud is, (and some are really cheapskate) you might need resources you don't have to set up the new architecture so you scrap and salvage the legacy https proxies, use the former https proxy load balanced cluster to provision the new architecture, and roll the whole new thing out. I've done stuff like that, well, there are differing details but more or less yeah.
Another classic is the cloudy forklift upgrade. Back in the bad old days you'd swap a physical rack of stuff one night and hope for the best (been there done that) but in cloudy land you provision new servers. But a lot of cloudy contracts and budgets are strangled technologically by very detailed quotas such that whats technically easy and wise would involve 50 people in the billing department pulling their hair out and its organizationally less suffering to yank the https cluster, reprovision your quota as half size/failed architecture 2.0, deploy 2.0 next week, if it doesn't blow up then pull architecture 1.0 and reprovision those quota as the other half of load balanced arch 2.0, depending how busy 2.0 is, you might have to do that quickly or take your time...
Either way, for a week or so, sure no https because what was doing https is turning into some other piece of infrastructure.
Not the worst of ideas... if you're changing two things, do two maint notifications. If they tried too much complicated stuff at one time and blew it up we'd be making fun of them for overscheduling.
The next obvious question is you're changing two things why not adjacent nights? Well look at all the paperwork BS and unless it involves launching nuclear missiles the .gov doesn't really operate that well so the contractors are going to bill one job on the monthly budget in April and the other job on the monthly budget in May. And there's a gap in case of delays and such. Maybe even separate contractors are involved for each maint which would be hilarious.