Problem with version 20161014.1604

[xbraumann]

Hej!

I am using Emacs 25.3 on a Mac, having biblio-20161014.1604 with biblio-core-20160901.1115 installed. I got

error in process filter: Could not create connection to data.crossref.org:443

when running the example from your GitHub Introduction: M-x crossref-lookup RET fiat deductive delaware RET I After hitting I the error appears, so I receive the search results, but can not insert the selected publication.

This happens, when I run this in an org-file (being in org major mode).

If I go to a bib file, being in BibteX mode, and run M-x doi-insert-bibtex RET 10.1145/2775051.2677006 RET

the whole HTML, javascript content of a web-site is pasted into the bib file (don't want to copy paste the whole content, its just HTML, javascript code).

ok, I am sorry for the unclear reporting; if there is something else I could add to make things clearer, please let me know.

Thank you! Alex

[cpitclaudel]

Hi Alex,

Thanks for the report! I think it would help to see the HTML; something looks rather wrong indeed. Could you try to reproduce these errors after running M-: (setq url-debug t) RET? This should create a *URL-DEBUG* buffer, with hopefully useful contents.

[xbraumann]

Hej!

I opened a .bib file and then did this (in BibTeX mode): 1) M-: (set url-debug t) RET 2) M-x doi-insert-bibtex RET 10.1016/j.jeconom.2017.04.002 The first time it refused connection, as described in my first message.

The second time I did this I got the following:

This is the content of URL-DEBUG:

http -> Contacting host: doi.org:80 http -> Marking connection as busy: doi.org:80 # http -> Request is: GET /10.1016/j.jeconom.2017.04.002 HTTP/1.1 MIME-Version: 1.0 Connection: keep-alive Extension: Security/Digest Security/SSL Host: doi.org Accept-encoding: gzip Accept: / User-Agent: URL/Emacs

http -> Calling after change function url-http-wait-for-headers-change-function' for#' http -> url-http-wait-for-headers-change-function ( http doi.org:80) http -> Saw end of headers... ( http doi.org:80) http -> url-http-parse-response called in ( http doi.org:80) http -> Got a content-length, being smart about document end. http -> Calling initial content-length for extra data at end of headers http -> Marking connection as free: doi.org:80 # http -> url-http-parse-headers called in ( http doi.org:80) http -> url-http-parse-response called in ( http doi.org:80) http -> Parsed HTTP headers: class=3 status=303 http -> Contacting host: linkinghub.elsevier.com:80 http -> Marking connection as busy: linkinghub.elsevier.com:80 # http -> Finished parsing HTTP headers: nil http -> Spinning waiting for headers... http -> Request is: GET /retrieve/pii/S0304407617300477 HTTP/1.1 MIME-Version: 1.0 Connection: keep-alive Extension: Security/Digest Security/SSL Host: linkinghub.elsevier.com Accept-encoding: gzip Accept: / User-Agent: URL/Emacs

http -> Calling after change function url-http-wait-for-headers-change-function' for#' http -> url-http-wait-for-headers-change-function ( http linkinghub.elsevier.com:80) http -> Saw end of headers... ( http linkinghub.elsevier.com:80) http -> url-http-parse-response called in ( http linkinghub.elsevier.com:80) http -> Got a content-length, being smart about document end. http -> Calling initial content-length for extra data at end of headers http -> Marking connection as free: linkinghub.elsevier.com:80 # http -> url-http-parse-headers called in ( http linkinghub.elsevier.com:80) http -> url-http-parse-response called in ( http linkinghub.elsevier.com:80) http -> Parsed HTTP headers: class=2 status=200 http -> Found 2 Set-Cookie headers http -> Finished parsing HTTP headers: t http -> Marking connection as free: linkinghub.elsevier.com:80 # http -> Activating callback in buffer ( http linkinghub.elsevier.com:80): url-queue-callback-function ((:redirect "http://linkinghub.elsevier.com/retrieve/pii/S0304407617300477") [cl-struct-url-queue "http://doi.org/10.1016/j.jeconom.2017.04.002" #[257 "p\303\304\305\306\307!\310\"\311$\216\301\206\312 \210\31319\314!\211\203*\315
\302\"\210\300
!\2023\316 \210e`|\210\300 \262
0\202?\317\320\"\262
)\207" [#[256 "\301
\300\"\207" [#[257 "\211\203\301
!\207\302\300\301\"\207" ["10.1016/j.jeconom.2017.04.002" #[257 "\301
\300\"\207" [# biblio-doi--insert] 4 "

(fn RESULT)"] biblio-doi--forward-bibtex-crosscite] 4 "

(fn RESULT)"] biblio-doi--generic-url-callback-1] 4 "Handle response from BibTeX server.

(fn &optional ERRORS)"] biblio-doi--restore-mime-accept ((http . 406)) make-byte-code 0 "\301\300!\207" vconcat vector [kill-buffer] 2 ignore (error) biblio--extract-errors biblio--throw-on-unexpected-errors biblio--beginning-of-response-body message "Error while processing request: %S"] 8 "

(fn EVENTS)"] nil nil #<buffer http doi.org:80> 1510615020.879428 t nil]) http -> Spinning waiting for headers...

This is the HTML parsed into the bib File

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta charset="utf-8">
<META http-equiv=Content-Type content="text/html">
<meta HTTP-EQUIV="REFRESH" content="2; url='/retrieve/articleSelectSinglePerm?Redirect=http%3A%2F%2Fwww.sciencedirect.com%2Fscience%2Farticle%2Fpii%2FS0304407617300477%3Fvia%253Dihub&amp;key=4175c019bda17407f25ef6824af9ce718ce83d32'"/>
<script type="text/JavaScript" src="/retrieve/static/script/siteCatalystHelper.js"></script>
<script type="text/JavaScript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js"></script>
<script src="https://assets.adobedtm.com/376c5346e33126fdb6b2dbac81e307cbacfd7935/satelliteLib-a986ae16a269f0e3b40c8a1e8e66d91745720dcd.js"></script>
<title>Redirecting</title>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<LINK title="Default Styles" href="/retrieve/static/css/articleLocatorNew.css"
    rel=stylesheet>
<LINK title="Default Styles" href="/retrieve/static/css/updateForm.css" rel=stylesheet>
<script language=JavaScript type="text/javascript">
var timerStart = Date.now();
var pageName = "Auto Article Locator";
    function autoRedirectToURL() {
        var url = '/retrieve/'+document.getElementById('resultName').value+'?Redirect='+document.getElementById('redirectURL').value+'&key='+document.getElementById('key').value
        try{siteCatalyst.clickEventTrack(document.getElementById('id').value);}catch(e){}
        window.location = url;
    }
</script>
</head>
<body onload="autoRedirectToURL();">
    <tr style="display:none;">
  <td colspan="2">
<input type="hidden" name="redirectURL" value="http%3A%2F%2Fwww.sciencedirect.com%2Fscience%2Farticle%2Fpii%2FS0304407617300477%3Fvia%253Dihub" id="redirectURL"/>  </td>
</tr>

    <tr style="display:none;">
  <td colspan="2">
<input type="hidden" name="key" value="4175c019bda17407f25ef6824af9ce718ce83d32" id="key"/>  </td>
</tr>

    <tr style="display:none;">
  <td colspan="2">
<input type="hidden" name="id" value="S0304407617300477" id="id"/>  </td>
</tr>

    <tr style="display:none;">
  <td colspan="2">
<input type="hidden" name="resultName" value="articleSelectSinglePerm" id="resultName"/>  </td>
</tr>

</body>
<script>
        siteCatalyst.pageDataLoad({
            businessUnit : 'ELS:RP:ST',
            environment : 'prod',
            language : 'en',
            loadTime : (Date.now()-timerStart).toString(),
            loadTimestamp : Date.now().toString(),
            name : pageName,
            productName : 'IH',
            type : 'NP-GP',

            accessType : 'ih:anon_guest',
            ipAddress : '84.191.41.140'
        });
    </script>
</html>

Hope this helps.

I repeated this again, and the same happened. The first time I tried, I got the connection refused message, the second this this HTML output and the message in the debug buffer.

cheers Alex

[cpitclaudel]

Thanks, it helps a lot. I'm hoping to debug this this week-end.

[cpitclaudel]

Hi Alex,

Sorry for the long delay; this fell off my radar. Looking at this again, I think the first part of the issue is probably related to Emacs' handling of SSL certificates. The latest version improved that, so I'd recommend to try again in the latest release. Do you see an improvement? The second part looks like a redirection served in a weird way by the server; does it still occur?

Clément.