4 ms·
Reasons: - URI length limits (not just browsers, but also things like Jersey) - q-params are ugly and limiting by comparison to an arbitrari
by cryptonector 2y ago
Reasons:
- URI length limits (not just
browsers, but also things
like Jersey)
- q-params are ugly and limiting
by comparison to an arbitrarily
large and complex request body
with a MIME type
However, q-params are super convenient because the query is then part of the URI, which you can then cut-n-paste around. Of course, a convenient middle of the road is to use a QUERY which returns not just query results but also a URI with the query expressed as q-params so you can cut-n-paste it.
- EE84M3i 2y agoQuery params are also extremely commonly logged all over the place and so putting sensitive information in them is almost always a bad idea.
- cryptonector 2y agoOf course. The security considerations section does mention this as a feature of `QUERY`, saying that the `Location:` returned by the server should not encode all the details of the request. However it's also true that q-params effectively form part of the UI. I'm certain you've edited URIs before -- I have, and I know not-so-knowledgeable people who do it too. Striking a balance here is not easy. With `QUERY` the server can decide how much of the query to encode into the `Location:`, if any of it at all. The server might use knowledge of the "schema" that the query refers to, or it might use the syntax of the query (if it supports indicating sensitive portions), or it might only "link-shorten" the whole query.