Closed Bug 205431 Opened 21 years ago Closed 17 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: 17 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.