The 'application/pdf' Content-Type shouldn't have any parameters, but a
site was returning 'application/pdf;charset=ISO-8859-1', so instead just
look for the 'application/pdf' prefix.
This should have been obvious, but we've been seeing Terminal when testing
because we're launching Zotero from the Terminal. Users with installed
Zotero version actually see 'Zotero' in instead of Terminal.
Also:
- Actually use the cookie sandbox passed to processDocuments()
For zotero/translation-server#16, we want to include Accept-Language
(and maybe other headers) from the client request in upstream requests,
which requires passing it to both non-translate processDocuments().
translation-server's non-translate processDocuments() is defined in that
repo, but it's called by the cross-repo translate processDocuments() in
utilities_translate.js, so the signature needs to be changed in both
repos.
We also apparently weren't using the cookieSandbox in client
processDocuments() calls, though I think that only would've affected
translator testing.
This fixes direct and VPN-based retrieval of PDFs for Elsevier (e.g.,
ScienceDirect) items that have a DOI but no URL, since Elsevier resolves
DOIs through an intermediate page.
This reverts commit e526a8fa89.
This is a repeat of a0ca67d879. The reverted changes break Scaffold.
This will need to be fixed in a way that allows Scaffold to continue to
work.
In 2652fac24 we started failing the translator if doGet/doPost returned
a >=400 status code, but at least one translator (Primo) relied on doGet
continuing after a 404. This allows translators to specify the status
codes that are allowed, similar to the same argument in
Zotero.HTTP.request().
(We'll clean up the signature at some point or just get rid of these
functions, but this is a quick fix for Primo.)
I didn't look into the details, but `this` isn't defined when this file
is loaded within Scaffold, so this line caused an error and the
translator tester was broken.
