From andrea at softinstigate.com  Tue Jun  4 06:53:49 2019
From: andrea at softinstigate.com (Andrea Di Cesare)
Date: Tue, 4 Jun 2019 12:53:49 +0200
Subject: [undertow-dev] proxing WebSocket over ajp listener
Message-ID: <CAKjer=FWsYQ-p08pfKZs1n-xT3+c2xFSCis+embes2HXW6kAsA@mail.gmail.com>

Hello Undertow lovers,

I have two instances of undertow, one acting as a reverse proxy via
LoadBalancingProxyClient  to the other that configured with the AJP
listener only.

Everything works well but I just noticed an issue with proxying WebSocket
connections.

I Googled around and it seems that APJ and WebSockets don't work together.

I was wondering if Undertow has some soluting for proxying WebSocket
connections over APJ or if I must fallback to http listener.

Any help would be much appreciated.

Thanks in advance,
 Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190604/eae502f7/attachment.html 

From sdouglas at redhat.com  Tue Jun  4 09:09:32 2019
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 4 Jun 2019 23:09:32 +1000
Subject: [undertow-dev] proxing WebSocket over ajp listener
In-Reply-To: <CAKjer=FWsYQ-p08pfKZs1n-xT3+c2xFSCis+embes2HXW6kAsA@mail.gmail.com>
References: <CAKjer=FWsYQ-p08pfKZs1n-xT3+c2xFSCis+embes2HXW6kAsA@mail.gmail.com>
Message-ID: <CAD+L2cwy0uDPONBRDN6Z7sxKGPA1UqTePJXka+cjUdHFi7oVpA@mail.gmail.com>

No, the AJP protocol does not support websockets. You need to use HTTP.

Stuart

On Tue, Jun 4, 2019 at 11:05 PM Andrea Di Cesare <andrea at softinstigate.com>
wrote:

> Hello Undertow lovers,
>
> I have two instances of undertow, one acting as a reverse proxy via
> LoadBalancingProxyClient  to the other that configured with the AJP
> listener only.
>
> Everything works well but I just noticed an issue with proxying WebSocket
> connections.
>
> I Googled around and it seems that APJ and WebSockets don't work together.
>
> I was wondering if Undertow has some soluting for proxying WebSocket
> connections over APJ or if I must fallback to http listener.
>
> Any help would be much appreciated.
>
> Thanks in advance,
>  Andrea
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190604/5637cf01/attachment.html 

From me at yawk.at  Tue Jun 11 11:05:11 2019
From: me at yawk.at (Jonas Konrad)
Date: Tue, 11 Jun 2019 17:05:11 +0200
Subject: [undertow-dev] Response stream not auto closing for content length 0
Message-ID: <52fc9116-0d1f-9e18-4d67-e81dfc965e55@yawk.at>

Hey,

I was working on a web server implemented with undertow and came across 
a weird inconsistency. When setting the response content length of an 
exchange and then writing to its output stream, normally the output 
self-closes as soon as the proper content length is hit. However, it 
turns out that this does not happen when content length is zero. This 
leads to the response remaining open if you've previously dispatch()ed it.

The code in question is here: 
https://github.com/yawkat/aggressive-cache/blob/fcd59ef0d35d8cd6102eceed103f93e073507378/src/main/java/at/yawk/aggressivecache/CacheHandler.java#L70 
- the relevant bit goes as follows:

exchange.startBlocking();
exchange.dispatch();
... later ...
exchange.setResponseContentLength(body.length);
exchange.getOutputStream().write(r.body);

(I'm aware that I should avoid no-arg dispatch, and that I should be 
closing the output stream - this was a rushed side project)

I've tracked down the issue to this class: 
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/io/UndertowOutputStream.java

Normally, updateWritten(long) checks whether the content length has been 
reached and if so, closes the stream and writes the response. However, 
when passing an empty array to write(byte[], int, int), we run into a 
length check and updateWritten is never executed, and thus the stream is 
never closed.

Is this a bug? I know the issue came from me using undertow improperly, 
but it certainly is inconsistent. To me it seems like the idea here is 
to close the stream when the response is done, which does not happen 
when writing a 0-length array. However it could also be argued that 
outputstream.write(new byte[0]) should never do anything.

If this is a bug, I'll happily make an issue and a PR for it if that's 
better for you - it doesn't look like it's that much work.

Thank you,
- Jonas

From sdouglas at redhat.com  Tue Jun 11 18:48:51 2019
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 12 Jun 2019 08:48:51 +1000
Subject: [undertow-dev] Response stream not auto closing for content
 length 0
In-Reply-To: <52fc9116-0d1f-9e18-4d67-e81dfc965e55@yawk.at>
References: <52fc9116-0d1f-9e18-4d67-e81dfc965e55@yawk.at>
Message-ID: <CAD+L2cz=z2Q0ZZYWo+a1ZYG+FuXt6cAXhpfGWXiH9L_QbLgqNQ@mail.gmail.com>

I guess you could argue that this is a bug, but really you should not be
calling write() with a zero length byte array. You can file an issue if you
want but I am not really sure if this is something we want to fix.

Stuart

On Wed, Jun 12, 2019 at 2:19 AM Jonas Konrad <me at yawk.at> wrote:

> Hey,
>
> I was working on a web server implemented with undertow and came across
> a weird inconsistency. When setting the response content length of an
> exchange and then writing to its output stream, normally the output
> self-closes as soon as the proper content length is hit. However, it
> turns out that this does not happen when content length is zero. This
> leads to the response remaining open if you've previously dispatch()ed it.
>
> The code in question is here:
>
> https://github.com/yawkat/aggressive-cache/blob/fcd59ef0d35d8cd6102eceed103f93e073507378/src/main/java/at/yawk/aggressivecache/CacheHandler.java#L70
> - the relevant bit goes as follows:
>
> exchange.startBlocking();
> exchange.dispatch();
> ... later ...
> exchange.setResponseContentLength(body.length);
> exchange.getOutputStream().write(r.body);
>
> (I'm aware that I should avoid no-arg dispatch, and that I should be
> closing the output stream - this was a rushed side project)
>
> I've tracked down the issue to this class:
>
> https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/io/UndertowOutputStream.java
>
> Normally, updateWritten(long) checks whether the content length has been
> reached and if so, closes the stream and writes the response. However,
> when passing an empty array to write(byte[], int, int), we run into a
> length check and updateWritten is never executed, and thus the stream is
> never closed.
>
> Is this a bug? I know the issue came from me using undertow improperly,
> but it certainly is inconsistent. To me it seems like the idea here is
> to close the stream when the response is done, which does not happen
> when writing a 0-length array. However it could also be argued that
> outputstream.write(new byte[0]) should never do anything.
>
> If this is a bug, I'll happily make an issue and a PR for it if that's
> better for you - it doesn't look like it's that much work.
>
> Thank you,
> - Jonas
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20190612/da03559b/attachment.html 

From jai.forums2013 at gmail.com  Tue Jun 25 01:32:52 2019
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 25 Jun 2019 11:02:52 +0530
Subject: [undertow-dev]  Undertow 3.0 Announcement
In-Reply-To: <CAD+L2czQzGg7O64HNEKvUB-auj2JZWsCqMviw1KWDNQgyVdwPg@mail.gmail.com>
Message-ID: <3a0e9621-13ba-64ae-c2ef-158a556a5b6e@gmail.com>

Hi Stuart/Flavia,

In terms of branch management, what's the plan for merging the commits
that are going into (or have gone into) "master" branch of undertow, to
3.x branch? Should I issue dual PRs (one for master and other for 3.x)
wherever applicable for commits/fixes that aren't related to transport
layer?

-Jaikiran