On Wed, Jul 13, 2016 at 12:46 PM, Rémy Maucherat wrote:
> 2016-07-13 14:00 GMT+02:00 Violeta Georgieva :
>
> > Hi,
> >
> > I think the following part of the specification is important:
> >
> > "
> > In the event that an asynchronous operation times out, the container must
> > run through the foll
On Wed, Jul 13, 2016 at 8:00 AM, Violeta Georgieva
wrote:
> Hi,
>
> 2016-07-12 23:27 GMT+03:00 Rossen Stoyanchev :
> >
> > hi-
> >
> > Starting with Tomcat 8.0.35 when an async request times out, in a
> > subsequent error dispatch request.isAsyncStar
hi-
Starting with Tomcat 8.0.35 when an async request times out, in a
subsequent error dispatch request.isAsyncStarted() returns true. Previously
it returned false.
The Servlet spec says:
If this request has been dispatched using one of the AsyncContext.dispatch
methods since it was put
in asynch
A bit late to this but I've done quick sanity checks from a Spring
Framework perspective (framework tests, websocket, Servlet 3 async, Servlet
3.1 non-blocking) with no issues encountered.
On Mon, May 16, 2016 at 6:34 AM, Mark Thomas wrote:
> The following votes were cast:
>
> Binding:
> - alph
On Wed, May 11, 2016 at 6:22 PM, Mark Thomas wrote:
> The proposed Apache Tomcat 8.5.2 release is now available for voting.
>
> 8.5.2 corrects a regression found in 8.5.1.
>
> The major changes compared to the 8.5.0 release are:
> - Add the org.apache.catalina.servlet4preview package that can be
hi,
A public API for initiating an upgrade at runtime was removed [1] which
breaks WebSocket support in the Spring Framework. This API was previously
added to make up for a limitation in JSR-356. The hope was for it to be
picked up in a spec update but unfortunately there has been no movement
wha
On Wed, Jan 29, 2014 at 6:43 PM, Mark Thomas wrote:
>
>
> The proposed 8.0.1 release is:
> [ ] Broken - do not release
> [ ] Alpha - go ahead and release as 8.0.1 (alpha)
> [ ] Beta - go ahead and release as 8.0.1 (beta)
> [x] Stable - go ahead and release as 8.0.1 (stable)
>
Focused on testin
I can confirm that the issue with the empty Sec-WebSocket-Protocol header
also affects Chrome 31.0.1650.63.
The actual issue appears as an "Invalid UTF-8 sequence in header value"
message in the Chrome dev tool. Although I had read what Martin reported
for Chrome 32, I couldn't confirm it's the sa
On Wed, Sep 25, 2013 at 9:37 AM, Violeta Georgieva wrote:
> The proposed Apache Tomcat 7.0.45 release is now available for voting.
> This release candidate contains JSR-356 Java WebSocket 1.0 implementation.
> Note that use of this functionality requires Java 7.
>
> It can be obtained from:
> http
On Tue, Sep 24, 2013 at 11:40 AM, Mark Thomas wrote:
> The necessary update to the script that uploads those JARs to the Maven
> repo was missed. I think I have fixed it locally but need to test it
> from somewhere with connectivity. Unless the JavaOne Wifi is
> significantly better than yesterda
On Tue, Sep 24, 2013 at 11:40 AM, Mark Thomas wrote:
> Tomcat should already being the necessary unwrapping in lines 179-181.
> It isn't immediately clear to me why this isn't working as intended. Can
> you denug this and add some insight?
Indeed, the code does unwrap the request correctly but t
I am getting a ClassCastException when using (non JSR-356) upgrade,
i.e. WsServerContainer.doUpgrade:
Caused by: java.lang.ClassCastException:
org.springframework.security.web.servletapi.HttpServlet3RequestFactory$Servlet3SecurityContextHolderAwareRequestWrapper
cannot be cast to org.apache.catali
On Thu, Aug 15, 2013 at 6:47 PM, Mark Thomas wrote:
> This isn't going to be quite as simple as I first thought.
>
> The WebSocket client API requires Java SE 7 or later.
> The WebSocket server API requires Java EE 6 or later.
> Java EE 6 requires Java 6 or later.
> The WebSocket server API depend
On Mon, Jun 3, 2013 at 10:27 AM, Niki Dokovski wrote:
> On Mon, Jun 3, 2013 at 3:44 PM, Niki Dokovski
> wrote:Further
> on, if you choose to use connectToServer call that has the
> ClientEndpointConfig param you are losing the annotation approach as the
> first param of this call has to be an i
Is this expected to run successfully? I am seeing failures when running
with `wstest -m fuzzingserver`. For example in 9.1.3, when the test client
tries to send the message back, the fuzz server closes the connection with
status 1007 and reason "encountered invalid UTF-8 while processing text
messa
15 matches
Mail list logo
