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
https://github.com/boundlessgeo/GeoExplorer/blob/master/app/httpclient.js
which in turn is used by
https://github.com/boundlessgeo/GeoExplorer/blob/master/app/auth.js :
The troubled part:
exports.getStatus = function(request) {
var url = getAuthUrl(request);
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
});
exchange.wait();
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
http://www.eclipse.org/jetty/documentation/current/http-client.html 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 : )
Regards
On Mon, Jan 30, 2017 at 7:34 PM, Simone Bordet <sbor...@webtide.com> wrote:
> Hi,
>
> On Mon, Jan 30, 2017 at 6:45 PM, David Persson <persso...@gmail.com>
> 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
> > http://www.eclipse.org/jetty/documentation/current/http-client.html 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: http://docs.oracle.com/javase/7/docs/technotes/guides/
> security/jsse/ReadDebug.html
>
> --
> Simone Bordet
> ----
> http://cometd.org
> http://webtide.com
> Developer advice, training, services and support
> from the Jetty & CometD experts.
> _______________________________________________
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
