GlassFish May Close a Connection When a HTTP Client Delays Sending Full HTTP Request
(Doc ID 1316311.1)
Last updated on OCTOBER 27, 2020
Applies to:
Oracle GlassFish Server - Version 2.1 to 2.1.1 [Release 2.1]Information in this document applies to any platform.
Symptoms
This problem can occur when the client sends a HTTP request where the complete HTTP request line is sent using multiple packets.
For example, if the complete HTTP request was "POST /<uri>/xxxx HTTP/1.1", and the request is received spread over multiple TCP packets instead of one packet.
2. <space> <flush>
3. /<uri>/xxxx HTTP 1.1
Under these conditions, the GlassFish server may close the connection if the complete HTTP request does not arrive together.
We will use an example to help explain the issue. In this example, the client sends two chunked-encoded HTTP requests to a web service, using the SOAP protocol. This is what the requests look like:
Content-Type: text/xml; charset=ISO-8859-1
Host: <IPAddress>
User-Agent: <Agent-Name>
SOAPAction:
Transfer-Encoding: chunked
593
<data_first_chunk>
52f
<data_second_chunk>
POST /<uri>/xxxx HTTP/1.1
Host: <IPAddress>
User-Agent:<Agent-Name>
Transfer-Encoding: chunked
0
If the "POST /<uri>/xxxx HTTP/1.1" is sent in one TCP packet, the requests will be successfully handled, and you will see the following in the Glassfish access logs:
"yy.yy.yy.yy" "NULL-AUTH-USER" "17/Mar/2011:10:42:07 +0000" "POST/<uri>/xxxxHTTP/1.1" 200 0
A TCP/IP trace, using the Wireshark packet capture utility, will look like this:
1 0.000000 xx.xx.xx.xx yy.yy.yy.yy TCP 56087 > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1260 WS=3 TSV=931073790 TSER=0
2 0.000132 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56087 [SYN, ACK] Seq=0 Ack=1 Win=49920 Len=0 TSV=967825811 TSER=931073790 MSS=1460 WS=0
3 0.300191 xx.xx.xx.xx yy.yy.yy.yy TCP 56087 > http-alt [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSV=931073793 TSER=967825811
4 0.308231 xx.xx.xx.xx yy.yy.yy.yy TCP [TCP segment of a reassembled PDU]
5 0.308289 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56087 [ACK] Seq=1 Ack=5 Win=49920 Len=0 TSV=967825842 TSER=931073793
6 0.634348 xx.xx.xx.xx yy.yy.yy.yy TCP [TCP segment of a reassembled PDU]
7 0.634406 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56087 [ACK] Seq=1 Ack=1253 Win=48672 Len=0 TSV=967825875 TSER=931073796
8 0.958174 xx.xx.xx.xx yy.yy.yy.yy TCP [TCP segment of a reassembled PDU]
9 0.964839 xx.xx.xx.xx yy.yy.yy.yy HTTP POST /<uri>/xxxx HTTP/1.1
10 0.964906 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56087 [ACK] Seq=1 Ack=2977 Win=49920 Len=0 TSV=967825908 TSER=931073799
11 0.969839 yy.yy.yy.yy xx.xx.xx.xx HTTP HTTP/1.1 200 OK
12 1.272744 xx.xx.xx.xx yy.yy.yy.yy TCP 56087 > http-alt [ACK] Seq=2977 Ack=747 Win=524280 Len=0 TSV=931073802 TSER=967825908
13 1.281119 xx.xx.xx.xx yy.yy.yy.yy TCP [TCP segment of a reassembled PDU]
14 1.390691 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56087 [ACK] Seq=747 Ack=2981 Win=49920 Len=0 TSV=967825951 TSER=931073802
15 1.694172 xx.xx.xx.xx yy.yy.yy.yy HTTP POST /<uri>/xxxx HTTP/1.1
16 1.697549 yy.yy.yy.yy xx.xx.xx.xx HTTP HTTP/1.1 200 OK
17 2.000365 xx.xx.xx.xx yy.yy.yy.yy TCP 56087 > http-alt [ACK] Seq=3220 Ack=950 Win=524280 Len=0 TSV=931073810 TSER=967825981
18 2.040256 xx.xx.xx.xx yy.yy.yy.yy TCP 56087 > http-alt [FIN, ACK] Seq=3220 Ack=950 Win=524280 Len=0 TSV=931073810 TSER=967825981
19 2.040297 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56087 [ACK] Seq=950 Ack=3221 Win=49920 Len=0 TSV=967826015 TSER=931073810
20 2.040703 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56087 [FIN, ACK] Seq=950 Ack=3221 Win=49920 Len=0 TSV=967826016 TSER=931073810
21 2.342488 xx.xx.xx.xx yy.yy.yy.yy TCP [TCP Dup ACK 18#1] 56087 > http-alt [ACK] Seq=3221 Ack=950 Win=524280 Len=0 TSV=931073813 TSER=967826015
22 2.351872 xx.xx.xx.xx yy.yy.yy.yy TCP 56087 > http-alt [ACK] Seq=3221 Ack=951 Win=524280 Len=0 TSV=931073813 TSER=967826016
Now, if the client sends the "POST /<uri>/xxxx HTTP/1.1" line in two (or more) TCP packets, as explained before, the issue will show up, and the GlassFish Server will close the connection before the client has completed sending the full POST request. The corresponding Wireshark capture showing this is:
43 46.166625 xx.xx.xx.xx yy.yy.yy.yy TCP 56551 > http-alt [SYN] Seq=0 Win=65535 Len=0 MSS=1260 WS=3 TSV=931107033 TSER=0
44 46.166691 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56551 [SYN, ACK] Seq=0 Ack=1 Win=49920 Len=0 TSV=968158545 TSER=931107033 MSS=1460 WS=0
45 46.466788 xx.xx.xx.xx yy.yy.yy.yy TCP 56551 > http-alt [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSV=931107036 TSER=968158545
46 46.474842 xx.xx.xx.xx yy.yy.yy.yy TCP [TCP segment of a reassembled PDU]
47 46.474902 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56551 [ACK] Seq=1 Ack=5 Win=49920 Len=0 TSV=968158576 TSER=931107036
48 46.783374 xx.xx.xx.xx yy.yy.yy.yy TCP [TCP segment of a reassembled PDU]
49 46.783433 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56551 [ACK] Seq=1 Ack=45 Win=49920 Len=0 TSV=968158607 TSER=931107039
50 47.092160 xx.xx.xx.xx yy.yy.yy.yy TCP [TCP segment of a reassembled PDU]
51 47.092604 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56551 [FIN, ACK] Seq=1 Ack=204 Win=49920 Len=0 TSV=968158638 TSER=931107042
52 47.417927 xx.xx.xx.xx yy.yy.yy.yy HTTP Continuation or non-HTTP traffic
53 47.417986 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56551 [RST] Seq=2 Win=49920 Len=0
54 47.417989 xx.xx.xx.xx yy.yy.yy.yy HTTP Continuation or non-HTTP traffic
55 47.418061 yy.yy.yy.yy xx.xx.xx.xx TCP http-alt > 56551 [RST] Seq=2 Win=0 Len=0
As seen above, in packet #51, GlassFish sends a FIN packet with no apparent reason, prematurely closing the connection. No access will be logged in GlassFish access logs.and the server.log show a finishConnection entry in FINEST logging.
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Cause |
| Solution |