Closed Bug 205431 Opened 22 years ago Closed 18 years ago

A non-blocking version of CERT_VerifyCert

Categories

(NSS :: Libraries, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 294531

People

(Reporter: wtc, Assigned: wtc)

Details

We need a non-blocking version of CERT_VerifyCert that fails with a "would block" error if any I/O operation (such as the network I/O for talking to an OCSP responder) required for verifying the cert is going to block. This doesn't need to be a new function if the current CERT_VerifyCert function can be made to operate in non-blocking mode.
QA Contact: bishakhabanerjee → jason.m.reid
QA Contact: jason.m.reid → libraries
libpkix now supports the non-blocking model, for OCSP, as well as cert/CRL fetching over LDAP and HTTP Even though CERT_VerifyCert could return a "would block" error, it doesn't save any context about the operation in progress, so there is no way to resume it later - it can only be restarted. I concluded that the prototype for CERT_VerifyCert was insufficient. A new prototype was required.
Target Milestone: --- → 3.12
This was supposed to be handled by the API introduced by bug 294531. Please look to see if that API handles this sufficiently, and if so, please mark this bug a duplicate of that one. As an aside, I will say that PSM does not intend to use this feature for FF3, and since (AFAIK) none of the server products use non-blocking I/O, I'm not sure this feature is needed AT ALL for 3.12. So, maybe this should be targeted for 3.13, if it's not already done.
Priority: -- → P3
The API is bug 294531 does support NBIO . Need I remind you that you were the one who insisted about the need for NBIO support in PKIX throughout its development ? We spent a lot of time making it work. Hopefully PSM will use the feature post FF3. One of our servers uses NBIO also.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Julien, I think PSM will come to regret its decision not to use NBIO for cert verification. I believe the decision not to use NBIO in PSM was based on the acceptable performance of the old API, which never goes and fetches anything over the network. When the performance of the new interface is seen, with the network induced delays, I think the decision not to use NBIO will be revisited. Nonetheless, today PSM is not using and is not planning to use the NBIO feature that we put there for its benefit.
You need to log in before you can comment on or make changes to this bug.