Summary

The URI specifications say explicitly/implicitly that invalid values for URI parameter strings should result in warn-and-ignore and not an error, except for those parameters that are explicitly marked as such (e.g. bad auth settings should reject the URI rather than warn-and-ignore). (Other parameters, specifically booleans, do warn-and-accept for certain strings, like journal=y, rather than just dropping the journal value entirely.)

Some spec test cases (e.g. read-write-concern, max-staleness), assert that URI parsing rejects a URI with certain bad parameter value strings, but their corresponding spec documents do not mention this.

Spec documents and tests should be updated to agree on what URIs to accept, which to warn, and which to reject. It should be clear and unambiguous what values/combinations-of-values for URI parameters should cause a rejection. Currently, this information is spread across multiple documents.

Motivation

Who is the affected end user?

This affects driver developers in how they implement our URI parsing and validation, which is currently full of many special cases. This can also affect end users that rely on certain URI parsing behaviors that could differ between implementations.

How does this affect the end user?

This doesn't call out any specific behavioral change, but it is possible that normalizing accept/warn/reject behavior could change the observable API surface across drivers.

How likely is it that this problem or use case will occur?

The behavior in question is related to the error-handling case of URI parsing. Well-formed URI strings with no invalid settings should not change, but those with abnormal values might need to be rejected/accepted-with-warnings.

If the problem does occur, what are the consequences and how severe are they?

Changing a result from rejection to warn-and-ignore will cause previously-invalid URI strings to be accepted and log new messages related to the bad parameters. Changing a previously-accepted URI to be rejected is not ideal, and is not proposed here.

Is this issue urgent?

This issue is not urgent. This is related to behavioral uniformity and focuses on reducing URI parsing complexity.

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

Possibly; If the existing test cases are ruled to be incorrect, then the drivers that assert on those cases will need to be modified. If the tests are ruled to be correct, and only the specification docs need to be updated, then no behavioral change is required.

Acceptance Criteria

It should be unambiguous and easy to look up the URI validation behavior for any given named parameter. Ideally, it should not require searching through several different documents to decide what behavior to adopt (e.g. uri-options could be updated to contain specifics on validation, or could refer to specific sections that exist in other documents).