Using cygwin curl in w32 Emacs fails to process a request about org-jira HOT 8 CLOSED

Apparently, I've been flush with free time today. I installed a w32-natively compiled curl and put it into my Windows' PATH variable before the cygwin/bin tools.

I had to still pop the cygwin/bin path from my emacs' exec-path, and verified that w32 emacs is now pointed to the new w32 curl via find-executable.

I ran org-jira-get-issue with a known issue and -- it works! The blame goes entirely on me for running a frankenmacs setup.

I'm not sure if there is a good way for me to still use the cygwin binaries for the tools that do work well but only use this specific w32 curl, but I will hack around more on my own.

from org-jira.

Also, if I go the URL specified at the end of the curl statement (http://company.jira.com/rest/api/2/search) in my browser after I sign in from the browser, I get the first 50 issues out of all issues logged in our jira, which I think is the content that org-jira is looking for to parse.

from org-jira.

Looks like this is a Windows-specific issue. Running the same emacs version and org-jira version on a remote Linux box and everything is working as expected.

from org-jira.

Hi, did you get to diagnose it any further? It seems like it may be something related to the JSON object encoding on Windows (I'm making a guess here, due to the unexpected character that was encountered in the JSON string).

from org-jira.

The only other thing I was able to try was using the specific commit for request.el from #17 that @mfehlhaber identified as the commit before a regression was introduced. Unfortunately, that did not fix the issue for me. Originally I was running of of whatever is the latest from melpa.

I'll try to dig into the request body that I'm getting back from the API to see what the issue is. If I can grab the request body from my Linux box as well as my Windows box, I'll see if there's actually a difference.

I'll update again when I've got something more to look at.

from org-jira.

I think I have an idea of what the issue is. I have cygwin installed on my system for SSH, git, etc, and have emacs interface with the cygwin CLI tools for as much of the work as I can. Somehow my win32 emacs is picking up cygwin's curl and is using that to make the call to jira via request.el.

In the defun for request, there's some code that determines which backend to use:

(apply (if sync
             (request--choose-backend 'request-sync)
           (request--choose-backend 'request))
         url settings)

On my Linux box, this was returning request--curl-sync but was returning request--curl on the w32 emacs. I hacked the request--choose-backend function to only return the request--curl-sync symbol but that still resulted in the same error. The value of the sync symbol in the above snippet was 't' for both systems.

At this point, I'm wondering that it might be an issue between cygwin's curl and a curl compiled specifically for w32.

To briefly test this, compiled emacs from source directly under cygwin (the w32 build I am using is directly from the GNU mirror) and loaded my same config... And now everything works! Of course, now that means that I would have to deal with how painfully slow cygwin emacs is, but that is not your issue.

If I have time tomorrow, I will try to have my w32 emacs load a curl that was been compiled specifically for w32 and see if that fixes things.

Edit: for anyone who cares, I went back and re-installed request.el to the latest version on melpa. Everything that I ran above was run on the latest commit as of writing.

from org-jira.

Awesome analysis, thanks for digging into this further!

from org-jira.

For those who may have found this issue but are still unable to get curl to work after updating it, it may be a problem of missing certificates, as described in issue #39. A straightforward explanation of how to add the missing certificates can be found here.

from org-jira.