Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jetty-users] curl: (56) Unexpected EOF

Thank you for jetty.  I've been using it for a few years now and love it.  Especially that I can configure it programmatically (with Kotlin code) and that you have updated the SSL/TLS protocol defaults over time.  Such an improvement over Tomcat!

Problem
My problem may be jar-file/classpath related and not jetty related, but then why does jetty actually call my code, service the request, but not return the response?

I recently enabled HTTP/2 (Google wants that for a Progressive Web App).  Now if I run my app the way IntelliJ does, giving the compiled classes directory, then adding all the jar dependencies it works. `java -classpath classes/:bunch-of-jar-files... MainClassName` it works.  But if I run from the fat-jar file it doesn't work.

curl

Jar File Failure:
$ curl --insecure https://dev.memoryjoggerlibrary.com:8443 -D headers.txt
curl: (56) Unexpected EOF
$ ls -s
total 0
0 headers.txt

Class Files Success:
That same curl command returns the HTML file I was expecting when running with the massive classpath (no fat-jar), plus the following headers.txt:
HTTP/2 200
server: Jetty(9.4.20.v20190813)
content-type: text/html;charset=utf-8

I have determined that the jar files included by maven exactly match the jar files specified on the command line.

Chrome
With chrome, the class files work great, but the Jar file produces, "This site can’t be reached... unexpectedly closed the connection... ERR_CONNECTION_CLOSED"

Unaffected
Log Files:
I can see in the log files in both cases that the request is being processed, but there is no exception thrown and no response apparently written.

Nmap Cipher Test:
Whether it yields HTML or not, the server gives the same response to my cipher test:
$ nmap --script ssl-cert,ssl-enum-ciphers -p 8443 dev.memoryjoggerlibrary.com

Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-02 13:32 EDT
Nmap scan report for dev.memoryjoggerlibrary.com (127.0.0.1)
Host is up (0.000053s latency).
rDNS record for 127.0.0.1: localhost

PORT     STATE SERVICE
8443/tcp open  https-alt
| ssl-cert: Subject: commonName=dev.memoryjoggerlibrary.com/organizationName=PlanBase Inc./stateOrProvinceName=Massachusetts/countryName=US
| Issuer: commonName=dev.memoryjoggerlibrary.com/organizationName=PlanBase Inc./stateOrProvinceName=Massachusetts/countryName=US
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-09-25T20:57:00
| Not valid after:  2022-09-25T20:57:00
| MD5:   483e 988f 709f 7300 3f3d 1d51 4f95 81cb
|_SHA-1: abe8 c872 c7d7 dfb1 4152 8bf3 2fee 5617 7613 94cd
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds

Details:
I'm using a self-signed certificate.

Currently using (from maven .pom):
<jetty.version>9.4.20.v20190813
jetty-server
jetty-alpn-conscrypt-server
http2-common
http2-hpack
http2-server

Not currently using: conscrypt-openjdk (seems to be overridden by the conscrypt-openjdk-uber included in jetty-alpn-conscrypt-server - same issues with or without this dependency)


--
Glen K. Peterson
(828) 393-0081

Back to the top