Problem with local server with Thunderbird

1

I’m trying to run a local server with the thunderbird addon : Grammar and Spell Checker — LanguageTool :: Add-ons for Thunderbird
I’ve installed that, downloaded LanguageTool-stable and run it using:
java -cp languagetool-server.jar org.languagetool.server.HTTPServer --allow-origin ‘*’ --public
The addon returns:
Oops…Cannot connect to http://localhost:8081/v2/check - please check your internet connection or try again in a minute (#1, code=undefined)
The server outputs:
2021-10-09 16:42:00.483 +0800 INFO org.languagetool.server.DatabaseAccessOpenSource Not setting up database access, dbDriver is not configured
2021-10-09 08:42:00 +0000 WARNING: running in HTTP mode, consider running LanguageTool behind a reverse proxy that takes care of encryption (HTTPS)
2021-10-09 08:42:01 +0000 Setting up thread pool with 10 threads
2021-10-09 08:42:01 +0000 Starting LanguageTool 5.5 (build date: 2021-10-02 12:33:00 +0000, 5e782cc) server on http://localhost:8081…
2021-10-09 08:42:01 +0000 Server started
2021-10-09 16:42:39.259 +0800 WARN org.languagetool.language.LanguageIdentifier Cannot consider noopLanguages because not in fastText mode: [en, zh]
2021-10-09 16:42:39.260 +0800 WARN org.languagetool.language.LanguageIdentifier Cannot consider noopLanguages because not in fastText mode: [en, zh]
2021-10-09 16:42:47.807 +0800 INFO org.languagetool.server.TextChecker Check done: 308 chars, en-US (mother tongue: en)[auto], requestId: null, #1, null, 0/1 matches, 8602ms, agent:webextension-unknown-ng, version: 4.1.1, sent, q:0, h:2, dH:1, r:2, m:tlo, premium: false
2021-10-09 16:42:50.062 +0800 INFO org.languagetool.server.TextChecker Check done: 312 chars, en-US (mother tongue: en)[auto], requestId: null, #1, null, 0/1 matches, 10871ms, agent:webextension-unknown-ng, version: 4.1.1, sent, q:0, h:1, dH:1, r:2, m:!tlo, premium: false

curl works:
curl ‘http://localhost:8081/v2/check?language=en-US&text=my+text’
{“software”:{“name”:“LanguageTool”,“version”:“5.5”,“buildDate”:“2021-10-02 12:33:00 +0000”,“apiVersion”:1,“premium”:false,“premiumHint”:“You might be missing errors only the Premium version can find. Contact us at supportlanguagetoolplus.com.”,“status”:“”},“warnings”:{“incompleteResults”:false},“language”:{“name”:“English (US)”,“code”:“en-US”,“detectedLanguage”:{“name”:“English (US)”,“code”:“en-US”,“confidence”:0.65618557}},“matches”:[{“message”:“This sentence does not start with an uppercase letter.”,“shortMessage”:“”,“replacements”:[{“value”:“My”}],“offset”:0,“length”:2,“context”:{“text”:“my text”,“offset”:0,“length”:2},“sentence”:“my text”,“type”:{“typeName”:“Other”},“rule”:{“id”:“UPPERCASE_SENTENCE_START”,“description”:“Checks that a sentence starts with an uppercase letter”,“issueType”:“typographical”,“category”:{“id”:“CASING”,“name”:“Capitalization”}},“ignoreForIncompleteSentence”:true,“contextForSureMatch”:-1}]}

So does accessing from a browser

LibreOffie Writer works when using “remote server”: http://localhost:8081
2021-10-09 16:46:07.958 +0800 INFO org.languagetool.server.TextChecker Check done: 27 chars, en-US, requestId: null, #1, null, 0/1 matches, 4311ms, agent:java-http-client, sent, q:0, h:1, dH:1, r:2, m:!tlo, premium: false

Thunderbird works when using: https://api.languagetool.org/v2/
Yay, no errors found!You can be proud of yourself

Obviously both the server and plugin work. But somehow not with each other in my case. Any idea what’s wrong?

2

It works for me using Thunderbird 91.2.0. Please make sure the parameter is

--allow-origin "*"

with exactly these types of quotes.

3

I tried double quotes first as that’s what the documentation says. The server just displays help. Leaving the argument blank gives:
Exception in thread “main” java.lang.IllegalArgumentException: Missing argument for ‘–allow-origin’ (e.g. an URL or ‘*’)
Using single quotes as per that message gives me a server that works with curl/wget, firefox, and LibreOffice but not the Thunderbird plugin.
What setup are you using where double quotes work?

I’m using Window 10, if that matters. Testing the server from windows cmd and cygwin bash
I upgraded to Thunderbird 91.2.0, It made no difference and thankfully didn’t break all my addons
java version “17” 2021-09-14 LTS
Java™ SE Runtime Environment (build 17+35-LTS-2724)
Java HotSpot™ 64-Bit Server VM (build 17+35-LTS-2724, mixed mode, sharing)

Here’s the verbose curl output which seems to show the server working fine:
$ curl -v ‘http://localhost:8081/v2/check?language=en-US&text=my+text’

  • STATE: INIT => CONNECT handle 0x800080148; line 1796 (connection #-5000)
  • Added connection 0. The cache now contains 1 members
  • STATE: CONNECT => WAITRESOLVE handle 0x800080148; line 1842 (connection #0)
  • family0 == v6, family1 == v4
  • Trying ::1:8081…
  • STATE: WAITRESOLVE => WAITCONNECT handle 0x800080148; line 1924 (connection #0)
  • Trying 127.0.0.1:8081…
  • Connected to localhost (127.0.0.1) port 8081 (#0)
  • STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x800080148; line 1987 (connection #0)
  • Marked for [keep alive]: HTTP default
  • STATE: SENDPROTOCONNECT => DO handle 0x800080148; line 2011 (connection #0)

GET /v2/check?language=en-US&text=my+text HTTP/1.1
Host: localhost:8081
User-Agent: curl/7.73.0
Accept: /

  • STATE: DO => DO_DONE handle 0x800080148; line 2082 (connection #0)
  • STATE: DO_DONE => PERFORM handle 0x800080148; line 2203 (connection #0)
  • Mark bundle as not supporting multiuse
  • HTTP 1.1 or later with persistent connection
    < HTTP/1.1 200 OK
    < Date: Sat, 09 Oct 2021 19:01:22 GMT
    < Content-type: application/json
    < Access-control-allow-origin: ‘*’
    < Content-length: 936
    <
  • STATE: PERFORM => DONE handle 0x800080148; line 2393 (connection #0)
  • multi_done
  • Connection #0 to host localhost left intact
  • Expire cleared (transfer 0x800080148)
    {“software”:{“name”:“LanguageTool”,“version”:“5.5”,“buildDate”:“2021-10-02 12:33:00 +0000”,“apiVersion”:1,“premium”:false,“premiumHint”:“You might be missing errors only the Premium version can find. Contact us at supportlanguagetoolplus.com.”,“status”:“”},“warnings”:{“incompleteResults”:false},“language”:{“name”:“English (US)”,“code”:“en-US”,“detectedLanguage”:{“name”:“English (US)”,“code”:“en-US”,“confidence”:0.65618557}},“matches”:[{“message”:“This sentence does not start with an uppercase letter.”,“shortMessage”:“”,“replacements”:[{“value”:“My”}],“offset”:0,“length”:2,“context”:{“text”:“my text”,“offset”:0,“length”:2},“sentence”:“my text”,“type”:{“typeName”:“Other”},“rule”:{“id”:“UPPERCASE_SENTENCE_START”,“description”:“Checks that a sentence starts with an uppercase letter”,“issueType”:“typographical”,“category”:{“id”:“CASING”,“name”:“Capitalization”}},“ignoreForIncompleteSentence”:true,“contextForSureMatch”:-1}]}
4

I start the server (LT 5.5) with this command:

java -cp languagetool-server.jar org.languagetool.server.HTTPServer --allow-origin "*"

Java is 1.8.0_301, OS is Ubuntu 20.04. I don’t think there’s any other setting I needed to change to make it work.

5

Does the Thunderbird error console (Tools → Developer Tools → Error console) show some useful debugging information, maybe?

6

Thanks. Good idea, and it helped be track down the problem, which had been staring me in the face all along. Using single quotes sets Access-control-allow-origin: to ‘*’, including the quotes. Using double quotes doesn’t work on Windows.Now that I think of it I’ve run into this before. It’s a known java bug. Running the server from Debian in WLS with double quotes worked.

I also found a solution. In case anyone else ever wants to run this on Windows locally this can be done by setting the allow-origin to moz-extension://e936e13d-c194-4f2a-bb66-76aa2386dfe3
java -cp languagetool-server.jar org.languagetool.server.HTTPServer --allow-origin moz-extension://e936e13d-c194-4f2a-bb66-76aa2386dfe3

7

I see. I have changed the --allow-origin option now so that it will work without a parameter in the future and that will imply * (here’s the commit).

According to this, the * doesn’t need to be in quotes at all on Windows. Can you confirm that?

8

Great idea. I was thinking out adding another option such as --allow-origin-all but that’s simpler.
I saw that stackoverflow thread, and a bunch of other discussions about the bug. Can confirm using no quotes is not a solution. It just displays help:
D:\Portable\LanguageTool-5.5>java -cp languagetool-server.jar org.languagetool.server.HTTPServer --allow-origin *
Usage: HTTPServer [–config propertyFile] [–port|-p port] [–public]
–config FILE a Java property file (one key=value entry per line) with values for:
…
Here’s a link to another stackoverflow question where it’s discussed in more details and a bug report

Apparently even though the problem is in java it’s Microsoft fault. What isn’t.

9

Just wanted to confirm I’ve built this, and it works as expected. Thanks.