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
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?
trepidacious
@trepidacious
@sbordet Ah cool, I hadn't realised they were versioned together until I got the dependency graph printed
Joakim Erdfelt
@joakime
@trepidacious Jetty is opensource, don't bother obfuscating it, there's nothing secret / proprietary to hide.
@zeeklumpkins you don't have sessions enabled? or a sessionhandler setup perhaps?
zeeklumpkins
@zeeklumpkins
@joakime that may be the question...what would be the call to establish that? I do set up a SessionHandler (setHttpOnly(true) and setSecure(true)) though do not know if there is a special call to use the session ids
trepidacious
@trepidacious
@joakime Ideally I'd rather just obfuscate everything, not so much to hide the open source code as make it harder to see what the the other code using it is doing
@joakime It might well be easier to just exclude everything in jetty packages though
Joakim Erdfelt
@joakime
@zeeklumpkins ServletContextHandler root = new ServletContextHandler(contexts, "/", ServletContextHandler.SESSIONS);
@trepidacious you are likely already excluding javax.* and java.* and sun.*, excluding org.eclipse.jetty.* is no different.
ProGuard only slows down someone, adds about 15 extra minutes to the process of decoding/deobfuscating.
you can thank the minecraft modding community for that. they have reverse-proguard tooling that a small army of volunteers have been working on for the past 10 years that works shockingly well for all proguarded source now.