[
https://issues.apache.org/jira/browse/HTTPCORE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCORE-196.
----------------------------------------
Resolution: Fixed
Committed patch to SVN trunk and 4.0.x branch
The snapshot builds can be found here
https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/
Oleg
> Long receive time for chunked ssl response
> ------------------------------------------
>
> Key: HTTPCORE-196
> URL: https://issues.apache.org/jira/browse/HTTPCORE-196
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0
> Environment: MacOSX (Leopard) / Tomcat / Eclipse
> Reporter: Scott Willey
> Fix For: 4.1
>
> Attachments: httpcore-196.patch
>
>
> Processing a chunked SSL response of 221 characters, I found I was waiting
> over three seconds for the entire response to be read. Upon investigation,
> this appears to be happening because the decrypt method in SSLIOSession does
> not decrypt everything in the encrypted buffer at one go. Because of this,
> portions of my response didn't get processed via the processing of the
> events, but rather via the BaseIOReactor's validate method which means I
> experienced multiple select interval timeouts prior to the message being
> fully processed. In reviewing the java nio documentation for the unwrap
> method of the sslEngine, the comments in the javadoc state: "This method will
> attempt to consume one complete SSL/TLS network packet". It appears that one
> time through the decrypt method decrypted small packets with almost no data
> in them, leaving encrypted data waiting. As an experiment, I changed the code
> in isAppInputReady in SSLIOSession to call decrypt in a loop until everything
> in the en
> crypted buffer was processed and bingo the response processed in under 5ms.
> Unfortunately, I do not have a "sharable" test case as the server side for
> this case is inside a corporate filrewall. In theory this should be
> reproducable with any server over an SSL connection getting a chunked
> response.
> I have a current "patch" for this issue as follows in
> SSLIOSession.isAppInputReady, but I will feel much more comfortable with and
> "official" patch
> public synchronized boolean isAppInputReady() throws IOException {
> int bytesRead = receiveEncryptedData();
> if (bytesRead == -1) {
> //changed per https://issues.apache.org/jira/browse/HTTPCORE-193
> // this.status = CLOSED;
> this.endOfStream = true;
> //end change
> }
> doHandshake();
>
> //MODIFICATION
> //Doing a single decrypt call does not always completely decrypt
> available
> //data (data read above in receiveEncryptedData). The documentation
> for
> //sslEngine states that the unwrap method (used in decrypt method)
> //
> // "This method will attempt to consume one complete SSL/TLS network
> packet"
> //
> //Presumedly, when there are multiple network packets, we only decode
> one
> //at a time, so multiple calls to decrypt may be necessary to decrypt
> all
> //we have. If we do not, we will not process all data available and we
> //will fail to process incoming responses in a timely way. This may
> cause
> //data to be processed only during calls to validation at the reactor
> level,
> //which is done once every selectInterval (default value: 1 sec)
>
> //original
> //decryptData();
>
> //change:
> int priorPos = 0;
> while(this.inEncrypted.position() > 0 && this.inEncrypted.position()
> != priorPos){
> priorPos = this.inEncrypted.position();
> decryptData();
> }
> //MODIFICATION END
>
> // Some decrypted data is available or at the end of stream
> return this.inPlain.position() > 0 || this.status != ACTIVE;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
