@trwnh
Greater than $20k in Credit Card Debt -- We Can Help
https://shorturl.at/toZJL

@trwnh oh good point, so if it's done by GET it *must* include the query parameters in the URL. And yeah, now I can see better why POST would be a better choice.

@oblomov there is one advantage to GET and that is the ability to share search results by copypasting a link to someone else or using it as an href

@trwnh @oblomov I'd add one additional benefit: they're infinitely easier to debug and test.

At least it's pretty common practice as I recall in Java EE to make an HttpServlet, generate doGet/doPost, and have doPost just call doGet, or vice versa.

Then GET URL calls let you diagnose what's being passed to which query parameter.

@AT1ST @oblomov eh, i'm more interested in doing what's right than doing what's easy

@trwnh No matter what assumption you make, you'll find some code out there that breaks that assumption. Everything web-related is a nightmare.

@trwnh My favourite part of that rabbit hole is that + is (erroneously?) not reserved in RFCs 1738 or 1630 (and 1630's second BNF production for "safe" includes +): https://datatracker.ietf.org/doc/html/rfc1738#page-20 https://datatracker.ietf.org/doc/html/rfc1630#page-26

This, along with the "and then" in HTML 2.0, results in enough ambiguity that space-plus could be encoded as "++" or "%2B%2B" depending on how you interpret the spec.

From RFC 1630, it looks like "search" strings were originally intended to represent space-separated (user-specified?) search terms, and I still occasionally see query strings that are bare search strings.

Another fun thing is that RFC 1808 adds generic ;-params separate from the query string (and RFC 2396 moves them to be part of path components), but they are rarely used in HTTP and were too late for HTML forms. (I'm not sure any RFC defines semantics for "directory" params, but they exist.)

@trwnh @AT1ST @oblomov and how is it any more “right” to obscure the thing that was searched for in your logs, to the user, and when sharing links?

I definitely see the case for a search API endpoint (not exposed to the user) being a POST (and elastic search does this), but our user facing search page is definitely a GET. Modified filters and the query text end up as query parameters.

Just because full text search is suddenly involved why is GET no longer appropriate?

@Charrondev @AT1ST @oblomov is /search?query=foo&limit=10 the same resource as /search?limit=10&query=foo to you? or is it two different resources with the same representation?

functionally it is about resource identity. calling POST /search with {“query”: “foo”, “limit”: 10} keeps it clear that the resource is /search. putting request params in the identity string is mixing concerns. this matters a lot more when designing protocols where uri equivalence is important. query normalization sucks.

@snowfox technology

@jbqueru for my purposes i was just curious about what ActivityPub might need to consider. since query component is opaque and query parameters aren’t real, it falls on the protocol level to specify how query strings should be parsed or normalized, if at all.

i think for now we can mostly just say that query strings SHOULD NOT be produced in identifiers, and if they are, they SHOULD be consistent with some over the top protocol/profile that defines normalization and parsing rules for the query

@Charrondev @AT1ST @oblomov more to the point of protocol design: the straightforward recommendation is don’t use query strings, or at least have the decency to normalize them according to some external protocol/profile that defines and specifies parsing and normalization rules. but then your peers need to agree on the protocol or profile.

@trwnh @AT1ST @oblomov well one massive negative to exposing your search as POST only is they your edge network can’t cache similar responses.

The query normalization doesn’t matter because the web app will ensure queries are in a consistent order.

As an example if you do /api/user/search?name=a* (such as in a mention lookup) then we can cache this response on our edge.

Now technically you could also cache a POST, but most edge networks can’t cache by body.

@Charrondev @trwnh @oblomov As I understand it, part of the problem is that the order of query parameters means that "search?query=foo&option=bar" caches differently than "search?option=bar&query=foo" - because if you don't do query normalization before caching, they "look" different to the cache.

@trwnh @oblomov I can understand that, but I suspect the reason the "Wrong" way of doing things persisted is because it *is* easier.

@AT1ST @oblomov right, html forms + cgi-bin popularized it massively

at least for my purposes though (personal services, protocol design) it is enough to say that we should avoid query components in identifiers or otherwise we must define a consistent way to normalize/canonize them.

more generally, identifiers SHOULD be expressed in normal form where possible to avoid issues like domain.example being different from domain.example/

@AT1ST @trwnh @oblomov this is true, however you can work around this by having the client code that generates URLs make them consistent. By and large end users are not typing URLs and certainly not query parameters.

@trwnh @jbqueru I think attempting any form of normalisation (beyond that specified by the URL spec) without involving the defining server is a complete fools errand tbh.

@Charrondev @AT1ST @oblomov there’s no standard for this, so it has to be defined at a protocol level

@erincandescent @jbqueru right, i was trying to figure out what the uri and http specs actually said. that’s how i found out that query params aren’t real and that query component normalization is a per-app/per-protocol thing

luckily nothing in activitypub depends on parsing query components, but we still need to worry about producing such ids in the first place (each server needs to be consistent if they’re going to do it)