From kontakt at lukaslentner.de  Fri Dec  8 02:48:45 2017
From: kontakt at lukaslentner.de (Lukas Lentner)
Date: Fri, 8 Dec 2017 07:48:45 +0000
Subject: [undertow-dev] Disable URL decoding when rewriting
Message-ID: <AM3PR02MB10098F6BFAE43075F66CAD5DBF300@AM3PR02MB1009.eurprd02.prod.outlook.com>

Hi,

I am using Wildfly 10.1.0.final which means undertow 1.4.0.final and I have the following problem. I configured my app with

WEB-INF/undertow-handlers.conf :
path-prefix('/application') -> rewrite('${remaining}')

This works pretty well, but when the rewrite is triggered it seems to once decode my URL. This is bad as my app will do the decoding at a central place once and thus the url will be decoded twice if the endpoint is called via /application/...

How can I circumvent that undertow decodes my url before rewriting?

Thankx
Lukas


----

Lukas Lentner, B. Sc.

St.-Cajetan-Stra?e 13
81669 M?nchen
Deutschland

Fon:     +49 / 89  / 44 38 61 27
Mobile:  +49 / 176 / 24 77 09 22

E-Mail:  Kontakt at LukasLentner.de
Website: www.LukasLentner.de

IBAN:    DE33 7019 0000 0001 1810 17
BIC:     GENODEF1M01 (M?nchner Bank)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20171208/dc0ff24c/attachment.html 

From sdouglas at redhat.com  Sun Dec 10 19:54:19 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 11 Dec 2017 11:54:19 +1100
Subject: [undertow-dev] Disable URL decoding when rewriting
In-Reply-To: <AM3PR02MB10098F6BFAE43075F66CAD5DBF300@AM3PR02MB1009.eurprd02.prod.outlook.com>
References: <AM3PR02MB10098F6BFAE43075F66CAD5DBF300@AM3PR02MB1009.eurprd02.prod.outlook.com>
Message-ID: <CAD+L2cxW5UviXFQwaiO9fNo4P1LnV-LOGL4QUaXsOzm1myW58Q@mail.gmail.com>

Rewrite should not affect the encoding, except for query parameters
referenced through
io.undertow.server.HttpServerExchange#getQueryParameters() which are
always decoded.

Are you sure this is related to the rewrite? In general Undertow will
decode all URI's to UTF-8 by default. If you want your app to handle
all the encoding yourself you can set
io.undertow.UndertowOptions#DECODE_URL to false, which will prevent
Undertow from doing any decoding.

This does have some drawbacks though, mostly that it is a global
setting that affects all applications.

Stuart

On Fri, Dec 8, 2017 at 6:48 PM, Lukas Lentner <kontakt at lukaslentner.de> wrote:
> Hi,
>
>
>
> I am using Wildfly 10.1.0.final which means undertow 1.4.0.final and I have
> the following problem. I configured my app with
>
>
>
> WEB-INF/undertow-handlers.conf :
>
> path-prefix('/application') -> rewrite('${remaining}')
>
>
>
> This works pretty well, but when the rewrite is triggered it seems to once
> decode my URL. This is bad as my app will do the decoding at a central place
> once and thus the url will be decoded twice if the endpoint is called via
> /application/?
>
>
>
> How can I circumvent that undertow decodes my url before rewriting?
>
>
>
> Thankx
>
> Lukas
>
>
>
>
>
> ----
>
>
>
> Lukas Lentner, B. Sc.
>
>
>
> St.-Cajetan-Stra?e 13
>
> 81669 M?nchen
>
> Deutschland
>
>
>
> Fon:     +49 / 89  / 44 38 61 27
>
> Mobile:  +49 / 176 / 24 77 09 22
>
>
>
> E-Mail:  Kontakt at LukasLentner.de
>
> Website: www.LukasLentner.de
>
>
>
> IBAN:    DE33 7019 0000 0001 1810 17
>
> BIC:     GENODEF1M01 (M?nchner Bank)
>
>


From kontakt at lukaslentner.de  Mon Dec 11 13:32:16 2017
From: kontakt at lukaslentner.de (Lukas Lentner)
Date: Mon, 11 Dec 2017 18:32:16 +0000
Subject: [undertow-dev] Disable URL decoding when rewriting
In-Reply-To: <CAD+L2cxW5UviXFQwaiO9fNo4P1LnV-LOGL4QUaXsOzm1myW58Q@mail.gmail.com>
References: <AM3PR02MB10098F6BFAE43075F66CAD5DBF300@AM3PR02MB1009.eurprd02.prod.outlook.com>
	<CAD+L2cxW5UviXFQwaiO9fNo4P1LnV-LOGL4QUaXsOzm1myW58Q@mail.gmail.com>
Message-ID: <AM3PR02MB1009D2C82C93E6DC9B66430ABF370@AM3PR02MB1009.eurprd02.prod.outlook.com>

Hi Stuart,

I am totally sure that my Path-Params get decoded twice and only if I use the rewrite feature. I make the same request to <SERVER>.../id=%252524
Once via the rewrite, once without the rewrite. My application sends me back the ID it received through JAX-RS PathParam and sends me back:
%2524 without and
%24 with rewrite

It is a simple JAX-RS Application without any decoding logic and only one rest endpoint. I am not even sure where the one decoding happens that I want to have (should be Resteasy, when it is providing the parameters to the resource method). But either way, if and only if I use the undertow rewrite I get %24 which is incorrect ...

Please have a look into this...

I have the possibility to remote debug the undertow when this happens. If there is any data I can provide to you that helps you track the error I am more than willing to do so ...

Bye
Lukas


----

Lukas Lentner, B. Sc.
 
St.-Cajetan-Stra?e 13
81669 M?nchen
Deutschland
 
Fon:     +49 / 89  / 44 38 61 27
Mobile:  +49 / 176 / 24 77 09 22
 
E-Mail:  Kontakt at LukasLentner.de
Website: www.LukasLentner.de

IBAN:    DE33 7019 0000 0001 1810 17
BIC:     GENODEF1M01 (M?nchner Bank)


> -----Urspr?ngliche Nachricht-----
> Von: Stuart Douglas [mailto:sdouglas at redhat.com]
> Gesendet: Montag, 11. Dezember 2017 01:54
> An: Lukas Lentner <kontakt at lukaslentner.de>
> Cc: undertow-dev at lists.jboss.org
> Betreff: Re: Disable URL decoding when rewriting
> 
> Rewrite should not affect the encoding, except for query parameters
> referenced through
> io.undertow.server.HttpServerExchange#getQueryParameters() which are
> always decoded.
> 
> Are you sure this is related to the rewrite? In general Undertow will decode
> all URI's to UTF-8 by default. If you want your app to handle all the encoding
> yourself you can set io.undertow.UndertowOptions#DECODE_URL to false,
> which will prevent Undertow from doing any decoding.
> 
> This does have some drawbacks though, mostly that it is a global setting that
> affects all applications.
> 
> Stuart
> 
> On Fri, Dec 8, 2017 at 6:48 PM, Lukas Lentner <kontakt at lukaslentner.de>
> wrote:
> > Hi,
> >
> >
> >
> > I am using Wildfly 10.1.0.final which means undertow 1.4.0.final and I
> > have the following problem. I configured my app with
> >
> >
> >
> > WEB-INF/undertow-handlers.conf :
> >
> > path-prefix('/application') -> rewrite('${remaining}')
> >
> >
> >
> > This works pretty well, but when the rewrite is triggered it seems to
> > once decode my URL. This is bad as my app will do the decoding at a
> > central place once and thus the url will be decoded twice if the
> > endpoint is called via /application/?
> >
> >
> >
> > How can I circumvent that undertow decodes my url before rewriting?
> >
> >
> >
> > Thankx
> >
> > Lukas
> >
> >
> >
> >
> >
> > ----
> >
> >
> >
> > Lukas Lentner, B. Sc.
> >
> >
> >
> > St.-Cajetan-Stra?e 13
> >
> > 81669 M?nchen
> >
> > Deutschland
> >
> >
> >
> > Fon:     +49 / 89  / 44 38 61 27
> >
> > Mobile:  +49 / 176 / 24 77 09 22
> >
> >
> >
> > E-Mail:  Kontakt at LukasLentner.de
> >
> > Website: www.LukasLentner.de
> >
> >
> >
> > IBAN:    DE33 7019 0000 0001 1810 17
> >
> > BIC:     GENODEF1M01 (M?nchner Bank)
> >
> >


From stevehu at gmail.com  Wed Dec 13 19:25:19 2017
From: stevehu at gmail.com (Steve Hu)
Date: Wed, 13 Dec 2017 19:25:19 -0500
Subject: [undertow-dev] ClientConnection shared by multiple threads
Message-ID: <CAGjN9KV+mSVS=D0soWf6wmiCSQ7HTeEHB1OyxtdjfObvG=4Hzw@mail.gmail.com>

Hi,

I saw the following comments in ClientConnection.java

A client connection. This can be used to send requests, or to upgrade the
connection.

In general these objects are not thread safe, they should only be used by
the IO thread that is responsible for the connection. As a result this
client does not provide a mechanism to perform blocking IO, it is designed
for async operation only.

The above comments made me to rethink what I have done with the
UndertowClient. I basically created a wrapper on top of UndertowClient so
that I can have one service calling another service with an HTTP 2.0
connection shared by multiple requests. As I understand the HTTP 2.0
connection supports multiplex so that you can have multiple requests sent
in the same channel in parallel.

Here is one of my examples and I have done some preliminary performance
test without any issue. I am wondering if I should cache the connect as
instance variable instead of static variable of HttpHandler.

https://github.com/networknt/light-example-4j/blob/master/rest/ms_chain/api_a/httpschain/src/main/java/com/networknt/apia/handler/DataGetHandler.java

Also, I realized that if downstream server is not in HTTP 2.0, then I need
to have a connection pool built in order to get better performance. Does
anybody have some example of HTTP connection pool implementation?

Thanks,

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20171213/6b39c8ea/attachment.html 

From lbonco at gmail.com  Thu Dec 21 17:29:38 2017
From: lbonco at gmail.com (luca boncompagni)
Date: Thu, 21 Dec 2017 23:29:38 +0100
Subject: [undertow-dev] AjpServerRequestConduit hangs
Message-ID: <CAOzS1k0AQGM5QzDZ-Hqktn-DKpSnxvmCmePXOduGcJrZ8_MZmA@mail.gmail.com>

Hi to all,
We are using undertow 1.4.0 running in wildfly-10.1.0 and we are using
mod_jk as load balencer.

Some times, during some upload, mod_jk and undertow hags-up. Both are
reding from file descriptor.

We are able to capture traffic, If you want, I can upload the full
pcap, but here you can find a decoded export from wireshark.


=================== START DUMP =======================

No.     Time               Source                Destination
Protocol Length Info
   1157 17:29:18,964405    10.248.4.81           10.248.4.99
AJP13    1212   0:REQ:Body

Frame 1157: 1212 bytes on wire (9696 bits), 1212 bytes captured (9696 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
1399449, Ack: 1195323, Len: 1146
Apache JServ Protocol v1.3
    Magic: 1234
    Length: 1142
    Data:

No.     Time               Source                Destination
Protocol Length Info
   1158 17:29:18,964540    10.248.4.81           10.248.4.99
TCP      4410   37092 ? 8007 [ACK] Seq=1400595 Ack=1195323 Win=342528
Len=4344 TSval=2468302997 TSecr=1035814060 [TCP segment of a
reassembled PDU]

Frame 1158: 4410 bytes on wire (35280 bits), 4410 bytes captured (35280 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
1400595, Ack: 1195323, Len: 4344

No.     Time               Source                Destination
Protocol Length Info
   1159 17:29:18,964563    10.248.4.99           10.248.4.81
TCP      66     8007 ? 37092 [ACK] Seq=1195323 Ack=1404939 Win=472448
Len=0 TSval=1035821158 TSecr=2468302997

Frame 1159: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1195323, Ack: 1404939, Len: 0

No.     Time               Source                Destination
Protocol Length Info
   1160 17:29:18,964584    10.248.4.81           10.248.4.99
AJP13    3914   0:REQ:Body

Frame 1160: 3914 bytes on wire (31312 bits), 3914 bytes captured (31312 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
1404939, Ack: 1195323, Len: 3848
[2 Reassembled TCP Segments (8192 bytes): #1158(4344), #1160(3848)]
Apache JServ Protocol v1.3
    Magic: 1234
    Length: 8188
    Data: -----------------------------123701544520758\r\nContent-Disposition:
form-data; name="img"; filename="blob"\r\nContent-Type:
image/png\r\n\r\n\211PNG\r\n\032\n

No.     Time               Source                Destination
Protocol Length Info
   1161 17:29:18,975994    10.248.4.99           10.248.4.81
AJP13    73     0:RSP:GET BODY CHUNK

Frame 1161: 73 bytes on wire (584 bits), 73 bytes captured (584 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1195323, Ack: 1408787, Len: 7
Apache JServ Protocol v1.3
    Magic: 4142
    Length: 3
    Code: GET BODY CHUNK (6)
    RLEN: 8186

No.     Time               Source                Destination
Protocol Length Info
   2123 17:29:26,465777    10.248.4.81           10.248.4.99
AJP13    3914   0:REQ:Body

Frame 2123: 3914 bytes on wire (31312 bits), 3914 bytes captured (31312 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
3035147, Ack: 1196716, Len: 3848
[2 Reassembled TCP Segments (8192 bytes): #2122(4344), #2123(3848)]
Apache JServ Protocol v1.3
    Magic: 1234
    Length: 8188
    Data: [truncated]

No.     Time               Source                Destination
Protocol Length Info
   2124 17:29:26,465799    10.248.4.99           10.248.4.81
TCP      66     8007 ? 37092 [ACK] Seq=1196716 Ack=3038995 Win=472448
Len=0 TSval=1035828659 TSecr=2468310498

Frame 2124: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1196716, Ack: 3038995, Len: 0

No.     Time               Source                Destination
Protocol Length Info
   2125 17:29:26,465909    10.248.4.99           10.248.4.81
AJP13    73     0:RSP:GET BODY CHUNK

Frame 2125: 73 bytes on wire (584 bits), 73 bytes captured (584 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1196716, Ack: 3038995, Len: 7
Apache JServ Protocol v1.3
    Magic: 4142
    Length: 3
    Code: GET BODY CHUNK (6)
    RLEN: 8186

No.     Time               Source                Destination
Protocol Length Info
   2126 17:29:26,502147    10.248.4.81           10.248.4.99
TCP      4410   37092 ? 8007 [ACK] Seq=3038995 Ack=1196723 Win=342528
Len=4344 TSval=2468310535 TSecr=1035828659 [TCP segment of a
reassembled PDU]

Frame 2126: 4410 bytes on wire (35280 bits), 4410 bytes captured (35280 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
3038995, Ack: 1196723, Len: 4344

No.     Time               Source                Destination
Protocol Length Info
   2127 17:29:26,502218    10.248.4.81           10.248.4.99
AJP13    3914   0:REQ:Body

Frame 2127: 3914 bytes on wire (31312 bits), 3914 bytes captured (31312 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
3043339, Ack: 1196723, Len: 3848
[2 Reassembled TCP Segments (8192 bytes): #2126(4344), #2127(3848)]
Apache JServ Protocol v1.3
    Magic: 1234
    Length: 8188
    Data [truncated]:

No.     Time               Source                Destination
Protocol Length Info
   2128 17:29:26,502232    10.248.4.99           10.248.4.81
TCP      66     8007 ? 37092 [ACK] Seq=1196723 Ack=3047187 Win=472448
Len=0 TSval=1035828695 TSecr=2468310535

Frame 2128: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1196723, Ack: 3047187, Len: 0

No.     Time               Source                Destination
Protocol Length Info
   2129 17:29:26,502450    10.248.4.99           10.248.4.81
AJP13    73     0:RSP:GET BODY CHUNK

Frame 2129: 73 bytes on wire (584 bits), 73 bytes captured (584 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1196723, Ack: 3047187, Len: 7
Apache JServ Protocol v1.3
    Magic: 4142
    Length: 3
    Code: GET BODY CHUNK (6)
    RLEN: 8186

No.     Time               Source                Destination
Protocol Length Info
   2130 17:29:26,502691    10.248.4.81           10.248.4.99
TCP      4410   37092 ? 8007 [ACK] Seq=3047187 Ack=1196730 Win=342528
Len=4344 TSval=2468310535 TSecr=1035828696 [TCP segment of a
reassembled PDU]

Frame 2130: 4410 bytes on wire (35280 bits), 4410 bytes captured (35280 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
3047187, Ack: 1196730, Len: 4344

No.     Time               Source                Destination
Protocol Length Info
   2131 17:29:26,502729    10.248.4.81           10.248.4.99
AJP13    3914   0:REQ:Body

Frame 2131: 3914 bytes on wire (31312 bits), 3914 bytes captured (31312 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
3051531, Ack: 1196730, Len: 3848
[2 Reassembled TCP Segments (8192 bytes): #2130(4344), #2131(3848)]
Apache JServ Protocol v1.3
    Magic: 1234
    Length: 8188
    Data: [truncated]

No.     Time               Source                Destination
Protocol Length Info
   2132 17:29:26,502739    10.248.4.99           10.248.4.81
TCP      66     8007 ? 37092 [ACK] Seq=1196730 Ack=3055379 Win=472448
Len=0 TSval=1035828696 TSecr=2468310535

Frame 2132: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1196730, Ack: 3055379, Len: 0

No.     Time               Source                Destination
Protocol Length Info
   2133 17:29:26,502873    10.248.4.99           10.248.4.81
AJP13    73     0:RSP:GET BODY CHUNK

Frame 2133: 73 bytes on wire (584 bits), 73 bytes captured (584 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1196730, Ack: 3055379, Len: 7
Apache JServ Protocol v1.3
    Magic: 4142
    Length: 3
    Code: GET BODY CHUNK (6)
    RLEN: 8186

No.     Time               Source                Destination
Protocol Length Info
   2134 17:29:26,508393    10.248.4.81           10.248.4.99
AJP13    204    0:REQ:Body

Frame 2134: 204 bytes on wire (1632 bits), 204 bytes captured (1632 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
3055379, Ack: 1196737, Len: 138
Apache JServ Protocol v1.3
    Magic: 1234
    Length: 134
    Data: [truncated]

No.     Time               Source                Destination
Protocol Length Info
   2135 17:29:26,508541    10.248.4.99           10.248.4.81
AJP13    73     0:RSP:GET BODY CHUNK

Frame 2135: 73 bytes on wire (584 bits), 73 bytes captured (584 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1196737, Ack: 3055517, Len: 7
Apache JServ Protocol v1.3
    Magic: 4142
    Length: 3
    Code: GET BODY CHUNK (6)
    RLEN: 8186

No.     Time               Source                Destination
Protocol Length Info
   2136 17:29:26,508751    10.248.4.81           10.248.4.99
AJP13    70     0:REQ:Body

Frame 2136: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: Vmware_a6:03:b3 (00:50:56:a6:03:b3), Dst:
Vmware_88:22:48 (00:50:56:88:22:48)
Internet Protocol Version 4, Src: 10.248.4.81, Dst: 10.248.4.99
Transmission Control Protocol, Src Port: 37092, Dst Port: 8007, Seq:
3055517, Ack: 1196744, Len: 4
Apache JServ Protocol v1.3
    Magic: 1234
    Length: 0

No.     Time               Source                Destination
Protocol Length Info
   2137 17:29:26,548349    10.248.4.99           10.248.4.81
TCP      66     8007 ? 37092 [ACK] Seq=1196744 Ack=3055521 Win=472448
Len=0 TSval=1035828742 TSecr=2468310541

Frame 2137: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Vmware_88:22:48 (00:50:56:88:22:48), Dst:
Vmware_a6:03:b3 (00:50:56:a6:03:b3)
Internet Protocol Version 4, Src: 10.248.4.99, Dst: 10.248.4.81
Transmission Control Protocol, Src Port: 8007, Dst Port: 37092, Seq:
1196744, Ack: 3055521, Len: 0


=================== END DUMP =======================

If I understand the protocol, undertow send two "GET BODY CHUNK" of
8186 length, bu mod_jk can send only 134 bytes, I think that the
upload finished, so undertow is waiting of filling the first "GET BIDY
CHUNK", but mod_jk is waiting for response.

Do you think that the following commit can solve my issue?

commit 13ed70fea27adba8317260ddb4b1dbdb4602471d
Author: Stuart Douglas <stuart.w.douglas at gmail.com>
Date:   Sat Feb 11 12:04:19 2017 +1100

    UNDERTOW-994 ajp connection hangs if a post HTTP request header
contains 'Transfer-Encoding: chunked'

Thanks,
Luca


From th_nabe at yahoo.com  Tue Dec 26 09:12:08 2017
From: th_nabe at yahoo.com (KT Nabe)
Date: Tue, 26 Dec 2017 14:12:08 +0000 (UTC)
Subject: [undertow-dev] Fw: Idiomatic POST body handling
In-Reply-To: <706929738.4492685.1514295299666@mail.yahoo.com>
References: <706929738.4492685.1514295299666.ref@mail.yahoo.com>
	<706929738.4492685.1514295299666@mail.yahoo.com>
Message-ID: <234588854.4500224.1514297528495@mail.yahoo.com>



     
----- Forwarded Message -----
 From: KT Nabe <th_nabe at yahoo.com>
 To: "undertow-dev at lists.jboss.org" <undertow-dev at lists.jboss.org> 
 Sent: Tuesday, December 26, 2017 5:34 AM
 Subject: Idiomatic POST body handling
   
Hello,
Is there an idiomatic/preferred/recommended way to configure an httphandler in such a way that it is invoked only after all of the request headers *and* body have been *both* drained (read from socket) and parsed?? Obviously would need a way to say, "parse entity/body bytes as String".
I've inferred that standard http-handlers are only invoked after the http headers have been drained and parsed, and that they are invoked on an io thread.Here's what I've been doing in the default handler:

if (exchange.isInIOThread()?? dispatch(this)
else? exchange.getRequestReceiver().receiveFullString(exchange ->? .....)
But it's occurred to me that this is inefficient, since I'm (I think):IO Thread -> dispatch -> Worker-Thread -> IO-Thread (to drain/parse body as String) -> WorkerThread (receiveFullString callback)
Now the above works, but I don't think it's optimal
I do want the receiveFullString callback to execute in an worker thread (since it blocks), this is why I included the initial dispatch call,? basically I just want a handler lambda to be:
if exchange.isInIOThread()?? assert?? body-has-been-fully-drained-and-parsed-as-string?? dispatch(this)else:? String body = exchange.getBodyAsString???.....
I'm assuming exchange.getRequestReceiver().receiveFullString is *always* asynchronous.What's the best way to do this, since it's such a common pattern?Thanks
?? 


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20171226/e493b6ea/attachment-0001.html