Entrez eSpell can't resolve PubmedSpellSrv

Another quick bug report blog post, this time NCBI Entrez's espell is currently broken returning:

Couldn't resolve #PubmedSpellSrv, the address table is empty.

Here's an example in full:

$ curl -v https://eutils.ncbi.nlm.nih.gov/entrez/eutils/espell.fcgi?term=biopythooon
*   Trying 165.112.7.20...
* TCP_NODELAY set
* Connected to eutils.ncbi.nlm.nih.gov (165.112.7.20) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: *.ncbi.nlm.nih.gov
* Server certificate: DigiCert SHA2 High Assurance Server CA
* Server certificate: DigiCert High Assurance EV Root CA
> GET /entrez/eutils/espell.fcgi?term=biopythooon HTTP/1.1
> Host: eutils.ncbi.nlm.nih.gov
> User-Agent: curl/7.54.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Fri, 27 Oct 2017 12:30:59 GMT
< Server: Apache
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
< Referrer-Policy: origin-when-cross-origin
< Content-Security-Policy: upgrade-insecure-requests
< Access-Control-Allow-Origin: *
< Cache-Control: private
< NCBI-PHID: 6ECE2B019F326F7100000000001A001A
< NCBI-SID: 6ECE2B019F327031_0026SID
< Content-Type: text/xml; charset=UTF-8
< Set-Cookie: ncbi_sid=6ECE2B019F327031_0026SID; domain=.nih.gov; path=/; expires=Sat, 27 Oct 2018 12:30:59 GMT
< Vary: Accept-Encoding
< X-UA-Compatible: IE=Edge
< X-XSS-Protection: 1; mode=block
< Transfer-Encoding: chunked
< 
<?xml version="1.0"?>
<!DOCTYPE eSpellResult PUBLIC "-//NLM//DTD eSpellResult, 23 November 2004//EN" "http://www.ncbi.nlm.nih.gov/entrez/query/DTD/eSpell.dtd">
<eSpellResult>
<Database/>
<Query/>
<CorrectedQuery/>
<SpelledQuery/>
<ERROR>Couldn't resolve #PubmedSpellSrv, the address table is empty.</ERROR>
</eSpellResult>
* Connection #0 to host eutils.ncbi.nlm.nih.gov left intact

As usual, in the absence of a public NCBI issue tracker, I will report this by email as well.

Note this also highlights an general problem with NCBI Entrez having horrible error handling - it fails to set an HTTP error code even on clear failures like this (you get HTTP 200 OK instead).29

Update (Sunday 29 October)

A surprise weekend email from the NCBI to my query (Ticket #28045-275380), this is working again and was presumably a transient error.