[DRIVERS-2072] Clarify behavior for conflicting TLS URI options Created: 05/Mar/20 Updated: 31/Mar/22 |
|
| Status: | Backlog |
| Project: | Drivers |
| Component/s: | URI Options |
| Fix Version/s: | None |
| Type: | Spec Change | Priority: | Major - P3 |
| Reporter: | Vincent Kam (Inactive) | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Driver Changes: | Needed | ||||
| Description |
|
Currently the spec is somewhat unclear as to what drivers should do when parsing conflicting TLS options when the driver does not implement one or more of the conflicting options. The spec currently defines combinations of TLS options that should result in an error here Option 1: Drivers should throw an error upon encountering a URI with conflicting TLS options if and only if the driver supports all the TLS options in the URI. This is somewhat implied by the current test plan: "Note that there are tests for each of the options marked as optional; drivers will need to implement logic to skip over the optional tests that they don’t implement." Option 2: Drivers should throw an error upon encountering a URI with conflicting TLS options, regardless of whether or not the driver supports all the TLS options in the URI. cc: divjot.arora |
| Comments |
| Comment by Vincent Kam (Inactive) [ 16/Mar/20 ] |
|
Based off previous discussions with sam.rossi and divjot.arora, I believe this is not a 4.4 blocker and have backlogged this ticket. |
| Comment by Jeffrey Yemin [ 16/Mar/20 ] |
|
Did we decide whether this is a 4.4 blocker, vincent.kam? If not, can we? |
| Comment by Vincent Kam (Inactive) [ 05/Mar/20 ] |
|
Note: If we go with option 2, the OCSP spec will need to be updated to note when errors must be thrown, as it currently mandates that errors should only be thrown when the driver supports the all the conflicting options. |