juanthropic commented on PR #13424: URL: https://github.com/apache/trafficserver/pull/13424#issuecomment-5919417394
Sorry for the long delay. I rebased onto master and the conflicts are resolved. > Do you only want a cache key that doesn't change depending on the ordering of parameters, or do you also want the origin server to see sorted parameters? The origin should see them. sort-destination is meant as a standalone operator in the set-destination / rm-destination family, and it's technically independent of the cache-key work. Cache-key sorting comes in a follow-up PR (sort-cache-key). The additive-hash idea fits the cache-key use case, so I'll look at that approach then. @zwoop, correct me if I'm wrong on your expectation that `sort-destination QUERY` is meant to be purely for query normalization meant to reach the origin. > check if the parameters are already in sorted order before allocating memory to sort them Yeah that's a great optimization. Done in fe1c2e890. > cachekey.so with --sort-params=true deduplicates parameters by name From getKeyQuery<StringSet>, cachekey.so puts whole name=value tokens into a std::set<std::string>. So it drops exact duplicate tokens and sorts by name, then value. sort-destination sorts only by name and keeps every param, with equal names in their original order. That's on purpose. Form-urlencoded queries are ordered lists that allow duplicates, and this operator changes what the origin receives. Looking into this, I think the cachekey.so dedup could cause issues of its own. With --sort-params, `?a=1` and `?a=1&a=1` share one cache entry, but an origin may answer them differently. Go's url.Query() and Python's parse_qs see three values in `a=1&a=1&a=1`, while PHP's $_GET keeps only the last. I don't know whether that dedup was a deliberate choice or something that should be addressed. The answer would also decide whether sort-cache-key should match it or keep duplicates. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
