DOI fetch broken on demo site about bibxml-service HOT 7 CLOSED

• This may be a regression, as it was previously tested against the previous demo IP per ietf-ribose#20 (comment). However, DOI logic did not change since that time.

• Alternatively, our new demo server infrastructure may fall within a DOI-blacklisted IP range. In that case it’s not an application-level bug but an infrastructure concern.

  I know that DOI blacklists IP ranges, because I was never able to get it to return anything besides 503 from my work machine, while the same cURL command worked fine on the old demo instance.

  For now I cannot try cURLing your reference from within demo infrastructure (no longer have SSH access), and because BibXML service misreports DOI’s 503 as 404 there’s no way of knowing. Once #34 is fixed, we’ll be able to identify whether DOI fetch regressed.

from bibxml-service.

I know that DOI blacklists IP ranges, because I was never able to get it to return anything besides 503 from my work machine, while the same cURL command worked fine on the old demo instance.

Interesting find!

@kwkwan can you do some investigation in this area and provide support to @strogonoff in accessing the infrastructure? Thanks.

from bibxml-service.

If that’s possible it’d be useful, but let’s not redeploy or push changes to bibxml-service today—I have many changes queued, including some post-refactor regression fixes and some improvements, so I’d rather avoid merge conflicts.

Also, while SSH access is convenient for testing access with cURL, I hope it will not be necessary in the end after the fix to bibxml-service (and possibly doi2ietf) is ready and we see HTTP 503’s from DOI properly.

I believe K8s-managed infrastructure is supposed to be immutable and configuration-driven, and does not lend itself easily to SSH access.

from bibxml-service.

Crossref changed their API. Their new API docs provide some details on etiquette and how to avoid running into throttling, which is nice.

from bibxml-service.

Also, while SSH access is convenient for testing access with cURL, I hope it will not be necessary in the end after the fix to bibxml-service (and possibly doi2ietf) is ready and we see HTTP 503’s from DOI properly.

@kwkwan is currently testing a new deployment that uses AWS resources and supports continuous deployment, will ping you when ready.

from bibxml-service.

This is nearly fixed. Crossref integration is for the time being handled within BibXML service (which uses crossrefapi and converts most of the response into consistent internal format in https://github.com/ietf-ribose/bibxml-service/blob/main/sources/doi/__init__.py). Can later be ported to doi2ietf-py.

from bibxml-service.

For the record, DOI fetch works now (try https://dev.bibxml.org/external-sources/doi/).

To add to my previous comment on implementation details, currently we cache results to reduce the number of requests to Crossref, so a change in DOI may not be reflected. Caching TTL may be moved to configuration, and/or we can allow user to re-retrieve while ignoring cache.

from bibxml-service.