Corrupting values in parameters: application responsibility?

[bodawei]

It isn't clear from the spec how these cases should be handled when building a request to be sent.

1. a header parameter that has "\r\n" in its value
2. a cookie with ";" in its value
3. a spaceDelimited value that has " " in it
4. a pipeDelimited value that has "|" in it
5. a label value with a "." in it
6. a matrix, form, or simple styled non-exploded value with "," in its values

I assume that OAS has no way to protect an app from itself in these circumstances, and so it is the responsibility of the app not to send data like this in these cases, or for an OAS client library to report an error if it is asked to do so.

(in terms of protecting an app from itself, cases like a path parameter which has "?" in its value and a query parameter that has "&" in its value can be dealt with by percent encoding these values before inserting into the URL)

[MikeRalphson]

I think it should be "must be dealt with by percent encoding" for components of the URL. But I see a possible need to forbid in the spec some of your enumerated problems above (such as the pipes one).

[bodawei]

FWIW, I've come to see that the percent encoding aspect for many of these isn't actually a pragmatic solution. Usually, at least, a query parameter value is simply "decodeURIComponent()"'ed, and that won't be able to distinguish between a delimiter that is percent encoded and a bit of data that is percent encoded. I think this forces either disallowing or an application-specific layer of additional decoding. :-(

[handrews]

The parts of this that we can deal with are being handled in the following (which address all delimiter confusion, not just spaces).

• Serialization of spaceDelimited query parameter with a list of strings. #3550
• Clarify spaceDelimited with spaces (3.0.4) #3723

Since this basically answers the question of this issue with a "yes, it's the application / user responsibility", I'm going to close this as a duplicate. If you think there's something else here, please comment and we can re-open.