Thanks!
On 5/15/09 9:20 AM, "Oleg Kalnichevski" <[email protected]> wrote: On Fri, May 15, 2009 at 12:17:11PM -0400, Scott Willey wrote: > Oleg, > > Sorry for being such a noodle, but I didn't see where the svn access was. Can > you point me in the right direction? > > Thanks > > Scott > Hi Scott I think this should get you started http://hc.apache.org/httpcomponents-core/source-repository.html Oleg > > On 5/14/09 2:12 AM, "Oleg Kalnichevski (JIRA)" <[email protected]> wrote: > > > > [ > https://issues.apache.org/jira/browse/HTTPCORE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Oleg Kalnichevski updated HTTPCORE-196: > --------------------------------------- > > Attachment: httpcore-196.patch > > There are test cases for chunk coded messages transmitted over SSL encrypted > connections in the HttpCore NIO test suite. So, I am not sure this issue is > easily reproducible. I suspect this may be a fairly uncommon fringe case. > Therefore, it would be helpful to understand the problem a bit better. Could > you please provide me with some details regarding the server side setup: OS, > web server, SSL library used? > > Anyways, please try out the attached patch and let me know if it fixes the > problem for you. Please note the patch is against SVN trunk, so you will have > to pull the latest code from the SVN repository, apply the patch and compile > the source. > > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
