Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] "early EOF" warning when https call from old application in 9.2.9.v2015022er

Hi, thanks for your reply.

The EOF call that yields a functional issue for the end user appears to be made from the 'server side' of this application to its neighbour application in the same Jetty9(and as such the same jre, 8), Geoserver. I don't see it when looking at traffic between an end user and the application. The application uses the jars mentioned in the original email, among others (8.1.16v20140903) jetty-client in which in turn is used by :

The troubled part:

exports.getStatus = function(request) {
    var url = "">    var status = 401;
    var headers = new Headers(request.headers);
    var token = headers.get("Cookie");
    var exchange = clientRequest({
        url: url,
        method: "GET",
        async: false,
        headers: headers
    return exchange.status;   //Status is 0, exchange.content is null for https url

where url == https://domain/geoserver/rest but the logs report it as GET//domain:443/geoserver/rest and if that is http://domain:443/geoserver/rest then our jetty9 can't handle that request, it gets aborted whether you try it from the application server or a client machine. It may be that we should configure jetty9 to understand and redirect http://domain:443 but I don't think just that would solve the issue, it is probably a bit of a tls configuration issue as you say since the official doc says "

When you create a HttpClient instance using the parameterless constructor, you will only be able to perform plain HTTP requests and you will not be able to perform HTTPS requests.

In order to perform HTTPS requests, you should create first a SslContextFactory, configure it, and pass it to the HttpClient constructor. When created with a SslContextFactory, the HttpClient will be able to perform both HTTP and HTTPS requests to any domain."

so I tried changing httpclient.js to import the util.ssl package and then create the httpclient like so:

var sslcontxtfctry = new SslContextFactory(true);
    var client = new HttpClient(sslcontxtfctry);

but this makes no perceivable difference. The GET is still to :443 and it still EOFs.

It is entirely possible that this issue is outside of the scope of this forum, if so I won't pursue it further.

If there's any further assistance to be had I shall of course be happy to receive it :  )


On Mon, Jan 30, 2017 at 7:34 PM, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:

On Mon, Jan 30, 2017 at 6:45 PM, David Persson <perssond9@xxxxxxxxx> wrote:
> Hi, yep, this was understood, and I knew I ran the risk of 0 replies, so I'm
> glad for yours : )
> Thanks for the info regarding EOF.
> This seems to happen for a specific request. The application instantiates a
> and
> issues a get request with an url argument that goes
> "https://domain.topdomain/path" but what is sent according to the jetty log
> appears to be "http://domain.topdomain:443" (I think- log says
> "GET//domain.topdomain:443/geoserver/rest" and the way our jetty9 is
> configured one can't reach it like this.

Mmm, that would be a gross bug that would have been reported ages ago.
Perhaps it's a logging bug, rather than an actual network protocol bug.

> It has to be
> http://domain.topdomain/path (for a 302) or https://domain.topdomain/path or
> https://domain.topdomain:443 . Am currently trying to instantiate an
> SSLContextFactory for the httpclient constructor but am so far not seeing an
> effect. It's obviously less "I know what I'm doing" and more "poke this and
> see if that part moves" but I am picking up a few things..

You should look at the server logs and try to understand why the
server rejects that request,
as the client has sent it (it is waiting for the response, but gets a
connection closed instead).

Especially, take a close look at what JDK you run on client and
server, what ciphers they have in common, what version of the TLS
protocol you have configured, etc.
My guess is that you have some TLS incompatibility between client and server.

See also:

Simone Bordet
Developer advice, training, services and support
from the Jetty & CometD experts.
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top