Re: [jetty-users] Problem reading POST body with embedded Jetty 12.0.x
Silvio, Let's get your existing code working but then I'd really like to show you how you can use jetty-12 handlers to do that expansion for you prior to any buffering and/or blocking input streams. cheers On Tue, 12 Sept 2023 at 03:47, Simone Bordet via jetty-users < jetty-users@eclipse.org> wrote: > Hi, > > On Mon, Sep 11, 2023 at 2:16 PM Silvio Bierman via jetty-users > wrote: > > > > It appears that all handling of POST requests with ZIP-content as > > payload in our application is broken with Jetty 12 (I tried both 12.0.0 > > and 12.0.1). We use an embedded Jetty-12 with ee10 and http/2. > > > > Using Jetty 11 the code works as expected. > > > > We post a ZIP-file from the command line using Curl to the application. > > The handling code wraps request.getInputStream in a BufferedInputStream > > wrapped in a ZipInputStream and starts reading ZipEntry objects with > > getNextEntry until this returns null. With Jetty 12 this code only > > manages to read the first part of the POST-body and then blocks > > indefinitely. This is not a multi-part request, the ZIP-content is > > simply used as the request payload. > > > > We have similar handling of ZIP-files posted from inside HTML pages > > (using JS FormData and XmlHttpRequest) and the same thing happens there. > > In this case the FormData is used to create a multi-part POST. > > > > Each time the first parts of the payload seems to be handled correctly. > > The initial entries are expanded and written to server side files > > correctly. > > > > No exceptions occur. The code just seems to block indefinitely with no > > CPU activity. > > > > Any ideas? Perhaps there is something wrong with our embedding code? > > Please open an issue with the code example, where it throws, and the > stack trace. > GH issues are better for this kind of analysis. > > Thanks! > > -- > 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 unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Problem reading POST body with embedded Jetty 12.0.x
Hi, On Mon, Sep 11, 2023 at 2:16 PM Silvio Bierman via jetty-users wrote: > > It appears that all handling of POST requests with ZIP-content as > payload in our application is broken with Jetty 12 (I tried both 12.0.0 > and 12.0.1). We use an embedded Jetty-12 with ee10 and http/2. > > Using Jetty 11 the code works as expected. > > We post a ZIP-file from the command line using Curl to the application. > The handling code wraps request.getInputStream in a BufferedInputStream > wrapped in a ZipInputStream and starts reading ZipEntry objects with > getNextEntry until this returns null. With Jetty 12 this code only > manages to read the first part of the POST-body and then blocks > indefinitely. This is not a multi-part request, the ZIP-content is > simply used as the request payload. > > We have similar handling of ZIP-files posted from inside HTML pages > (using JS FormData and XmlHttpRequest) and the same thing happens there. > In this case the FormData is used to create a multi-part POST. > > Each time the first parts of the payload seems to be handled correctly. > The initial entries are expanded and written to server side files > correctly. > > No exceptions occur. The code just seems to block indefinitely with no > CPU activity. > > Any ideas? Perhaps there is something wrong with our embedding code? Please open an issue with the code example, where it throws, and the stack trace. GH issues are better for this kind of analysis. Thanks! -- 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 unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12.0.1 build vs 12.0.0 build
Hi, On Mon, Sep 11, 2023 at 12:42 PM Silvio Bierman via jetty-users wrote: > > Revisiting this issue I can confirm that both building our Scala > application with JDK20 against Jetty 12.0.1 jars built from source with > JDK20 and building with JDK21 against the standard 12.0.1 jars (built > with JDK21) works. Apparently it is an issue with the Scala compiler not > being able to handle JKD21 built jars when itself running in JDK20. Do you have a reference to the Scala issue? -- 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 unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] Is OnWebSocketClose called after OnWebSocketError?
Hi, I'm using the Jetty WebSocket API (for Jetty 11, if that makes a difference). I'm looking at the documentation for the OnWebSocketError event, and it says that this will close the session. However, I'm unable to find out whether this will in turn trigger the OnWebSocketClose event. Essentially I want to know if I can put cleanup code under the OnWebSocketClose event, or if I have to also put it under OnWebSocketError to guarantee it executes if the websocket closes due to an error. -- James Reeves ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
[jetty-users] Problem reading POST body with embedded Jetty 12.0.x
It appears that all handling of POST requests with ZIP-content as payload in our application is broken with Jetty 12 (I tried both 12.0.0 and 12.0.1). We use an embedded Jetty-12 with ee10 and http/2. Using Jetty 11 the code works as expected. We post a ZIP-file from the command line using Curl to the application. The handling code wraps request.getInputStream in a BufferedInputStream wrapped in a ZipInputStream and starts reading ZipEntry objects with getNextEntry until this returns null. With Jetty 12 this code only manages to read the first part of the POST-body and then blocks indefinitely. This is not a multi-part request, the ZIP-content is simply used as the request payload. We have similar handling of ZIP-files posted from inside HTML pages (using JS FormData and XmlHttpRequest) and the same thing happens there. In this case the FormData is used to create a multi-part POST. Each time the first parts of the payload seems to be handled correctly. The initial entries are expanded and written to server side files correctly. No exceptions occur. The code just seems to block indefinitely with no CPU activity. Any ideas? Perhaps there is something wrong with our embedding code? Kind regards, Silvio ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12.0.1 build vs 12.0.0 build
Revisiting this issue I can confirm that both building our Scala application with JDK20 against Jetty 12.0.1 jars built from source with JDK20 and building with JDK21 against the standard 12.0.1 jars (built with JDK21) works. Apparently it is an issue with the Scala compiler not being able to handle JKD21 built jars when itself running in JDK20. Silvio On 04-09-2023 16:09, Silvio Bierman via jetty-users wrote: I can confirm that compiling works with jars that are built with. Cheers, Silvio On 04-09-2023 14:48, Simone Bordet wrote: Hi, On Mon, Sep 4, 2023 at 1:23 PM Silvio Bierman via jetty-users wrote: I have a strange issue that is probably not directly Jetty related but only occurs when I compile against the 12.0.1 jars and not when using the 12.0.0 jars so I was hoping for some info. My Scala compiler crashes with an internal error when compiling against the 12.0.1 jars and not when using the 12.0.0 jars. Jetty 12.0.0 has been compiled with Java 20 --release 17. Jetty 12.0.1 has been compiled with Java 21 --release 17. Could be that in Java 21 the javac compiler does something slightly different that scalac does not like. ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
