https://issues.apache.org/bugzilla/show_bug.cgi?id=53717
Priority: P2
Bug ID: 53717
Assignee: [email protected]
Summary: HTTPS Connector not buffering results correctly
Severity: normal
Classification: Unclassified
Reporter: [email protected]
Hardware: PC
Status: NEW
Version: 7.0.29
Component: Connectors
Product: Tomcat 7
Created attachment 29226
--> https://issues.apache.org/bugzilla/attachment.cgi?id=29226&action=edit
Sample client showing buffering
It appears that tomcat 7.0.29 under Java 1.6.0_33 is operating a bit strangely
in how it is buffering SSL responses (and differently from 1.6.0_25).
I have a web app that just has a single servlet that outputs a few thousand
characters of data (in valid html). Tomcat is set up to use the
Http11NioProtocol connector and a self-signed certificate.
If I try using a SSLSocket to read the data from the page every other chunk of
the data will have only a single byte, followed by a normal sized chunk. The
client just uses the normal OutputStream.read function passing in a large
buffer (source attached).
Sample Output-------------
Count of Bytes Read: 16384
Data:HTTP/1.1 200 OK
Ser--SNIP--defabcdefabcdefabcde
Count of Bytes Read: 1
Data: f
Count of Bytes Read: 275
Data:abcdefabcdefabcdefab--SNIP--cdefabcdefabcdefabcd
Count of Bytes Read: 1
Data: e
Count of Bytes Read: 1666
Data:fabcdefabcdefabcdefa--SNIP--y>
</html>
This behavior only happens with the secure connector. If use a non-secure
connector, the chunks are all sized similarly.
This is different from the behavior when tomcat is running using 1.6.0_25.
Under that version, the chunks appear to be normally-sized (no 1-byte chunks).
I've attached a sample client that uses a SSLSocket to connect directly to
tomcat and show how the buffering is working. I've confirmed that the version
of the client doesn't matter, the same issue happens regardless of whether I'm
using 1.6.0_25 or 1.6.0_33
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
