Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 23:02
    jebeaudet commented #3314
  • Jan 31 2019 22:50
    joakime commented #3314
  • Jan 31 2019 22:50
    joakime commented #3314
  • Jan 31 2019 22:48
    joakime commented #3314
  • Jan 31 2019 22:46
    olamy commented #2878
  • Jan 31 2019 22:45
    jebeaudet commented #3314
  • Jan 31 2019 22:41
    joakime commented #3314
  • Jan 31 2019 22:39
    joakime commented #3314
  • Jan 31 2019 22:26
    jebeaudet edited #3314
  • Jan 31 2019 22:24
    jebeaudet opened #3314
  • Jan 31 2019 17:28
    sbordet commented #3313
  • Jan 31 2019 17:20
    sbordet review_requested #3313
  • Jan 31 2019 17:20
    sbordet review_requested #3313
  • Jan 31 2019 17:20
    sbordet opened #3313
  • Jan 31 2019 17:18

    sbordet on jetty-10.0.x-1350-dynamic_client_transport

    Issue #1350 - Dynamic selection… (compare)

  • Jan 31 2019 16:37

    sbordet on jetty-10.0.x-132_client_connector

    (compare)

  • Jan 31 2019 16:37

    sbordet on jetty-10.0.x

    Issue #132 - ClientConnector ab… Issue #132 - ClientConnector ab… Issue #132 - ClientConnector ab… and 2 more (compare)

  • Jan 31 2019 16:37
    sbordet closed #3267
  • Jan 31 2019 16:15
    sbordet synchronize #3312
  • Jan 31 2019 16:15

    sbordet on jetty-9.4.x-3311-http_https_same_port

    Fixes #3311 - Ability to serve … (compare)

David J. M. Karlsen
@davidkarlsen
1;38;5;2mweb  | 2018-11-28 17:22:09.397:WARN:oejwc.XmlBasedHttpClientProvider:main: Unable to load: file:/app/resources/jetty-websocket-httpclient.xml
web  | java.lang.ClassNotFoundException: org.eclipse.jetty.client.HttpClient
I’ll post my config in the gist
Joakim Erdfelt
@joakime
the package org.eclipse.jetty.client is not exposed through the WebAppClassloader Isolation typically.
David J. M. Karlsen
@davidkarlsen
Hmmm I found the config in some github issue for jetty
howto configure proxy then?
Joakim Erdfelt
@joakime
ah, that's different then websocket
proxy is the proxy module in your ${jetty.base}
David J. M. Karlsen
@davidkarlsen
for a websocket client
David J. M. Karlsen
@davidkarlsen
?
David J. M. Karlsen
@davidkarlsen
ait - got it to work, added the config file on class path and added http://repo1.maven.org/maven2/org/eclipse/jetty/websocket/javax-websocket-client-impl/ to the app -> happytimes
onlysolace
@onlysolace
Hello! I was wondering if someone knows how I could redirect all HTTP requests on port 8080 to port 8443 on a Spring Boot project
but I am not sure how I can use it to add some kind of redirection rule
Joakim Erdfelt
@joakime
@onlysolace to redirect from HTTP to HTTPS means you'll have 2 ServerConnectors, each with their own HttpConfiguration. first, make sure that the HTTP ServerConnector / HttpConfiguration has the correct securePort / secureScheme values that point to the HTTPS connector.
Next, add the SecureRedirectHandler to your handler list (somewhere early, perhaps even the first entry)
For redirects, you can either use the Servlet API's .sendRedirect() from a Servlet
or you can use the Jetty RedirectHandler and whatever rules you want to attach to it.
just make sure that RedirectHandler sits before your application handlers in the handler tree.
onlysolace
@onlysolace
@joakime I got it working! Thank you so much :)
David (javalin.io)
@tipsy
if you throw an java.lang.Error in a servlet, jetty seems to retry the request. where can i find documentation about this?
Simone Bordet
@sbordet
@tipsy I guess what you see is that there is no error page defined, and Jetty redispatches the request with DispatcherType=ERROR to generate an error page
David (javalin.io)
@tipsy
thanks @sbordet, is there a page where i can read more about that?
Simone Bordet
@sbordet
@tipsy this is described in the servlet specification 3.1, section 10.9.2
David (javalin.io)
@tipsy
oh, i assumed it was jetty specific, thank you!
Ayaz
@hwasin

Hi. I've caught javax.net.ssl.SSLException: SSL peer shut down incorrectly exception on a client side. After debug enabled on jetty side i found out that Jetty failed to flush TLS close_notify(). I think this might be caused by socket sender buffer being full. I also read jetty source code and for some reason flushing close_notify() does not happen even it is commented so:

switch (wrapResultStatus)
                    {
                        case CLOSED:
                            // The SSL engine has close, but there may be close handshake that needs to be written
                            if (BufferUtil.hasContent(_encryptedOutput))
                            {
                                _cannotAcceptMoreAppDataToFlush = true;
                                getEndPoint().flush(_encryptedOutput);
                                getEndPoint().shutdownOutput();
                                // If we failed to flush the close handshake then we will just pretend that
                                // the write has progressed normally and let a subsequent call to flush
                                // (or WriteFlusher#onIncompleteFlushed) to finish writing the close handshake.
                                // The caller will find out about the close on a subsequent flush or fill.
                                if (BufferUtil.hasContent(_encryptedOutput))
                                    return false;
                            }

false returned value is not checked by caller

Following WA helps:
while(!getEndPoint().flush(_encryptedOutput) && i < 10) {
                                    try {
                                        Thread.sleep(10);
                                    } catch (InterruptedException e) {
                                        LOG.ignore(e);
                                    }
                                    i++;
}
Could you please share your thoughts on this issue?
Simone Bordet
@sbordet
@hwasin please open a GitHub issue about this and let's discuss it there
Ayaz
@hwasin
ok. thanks
Ayaz
@hwasin
@sbordet done
Matthew Pocock
@drdozer
hi - we're packaging up a jetty/vaadin application in docker, and have found that it is downloading the internet when the jetty service is started
is there a way to get it to do all those downloads during the maven phase, so that the docker image itself is ready to go?
Simone Bordet
@sbordet
@drdozer please open an issue and describe your problem with more details. If you pack your stuff using Jetty embedded there is no Maven and no downloads; if you use Jetty standalone, there is no Maven and no download; if you use Maven to start Jetty, that would be weird.
Joakim Erdfelt
@joakime
@drdozer note: jetty-maven-plugin is meant to aide in development, not for production. - See https://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html
"While the Jetty Maven Plugin can be very useful for development we do not recommend its use in a production capacity. In order for the plugin to work it needs to leverage many internal Maven apis and Maven itself it not a production deployment tool. We recommend either the traditional distribution deployment approach or using embedded Jetty."
David (javalin.io)
@tipsy
i want to add auth to websockets. my approach is to hook into the service() of a WebSocketServlet and only do the upgrade if the request is valid:
class MyWsSevlet : WebSocketServlet() {
    override fun service(req: HttpServletRequest, res: HttpServletResponse) {
        if (valid(req)) {
            super.service(req, res)
        } else {
            res.sendError(401, "Unauthorized")
        }
    }
}
is this an okay approach? can it be bypassed somehow?
Simone Bordet
@sbordet
@tipsy it's probably better to use a servlet filter so you have authn factored out into a single component
David
@david-wg2
this is pretty much all the code @sbordet (there is also a two-line override of configure), it seems a bit excessive to split this up
the main thing i need to know is if there are any cases where service will not be called when upgrading to WS, or if it will always be called
Simone Bordet
@sbordet
@david-wg2 I can't tell you if it's going to be called, depends on what you have in front of the servlet and how's mapped. If all things normal, yes it will be called
David
@david-wg2
nothing of note in front of it, it's mapped to /*
thank you!
Joakim Erdfelt
@joakime
@tipsy it's probably better to perform the auth check in the WebSocketCreator (or the ServerEndpointConfig.Configurator if using JSR356), that way the websocket layer can respond according to the RFC6455 (and RFC8441 in future release)
trepidacious
@trepidacious
I'm trying to obfuscate an app that uses jetty (via javalin) using proguard. It seems like there are references to things like org.eclipse.jetty.jmx.ObjectMBean in jetty that are not in the jetty dependencies - I think at least that one is in jetty-jmx. Is that expected? Should I have an explicit dependency on jetty-jmx to let proguard work?
If I should have a dependency on jetty-jmx, which version?
Simone Bordet
@sbordet
same version as the rest of jetty jars
zeeklumpkins
@zeeklumpkins
Hi there. I have an embedded jetty service in a java app, set up with https and a self signed cert...is there any reason when looking at headers in curl that I cannot see anything resembling a session id?