HTTP-proxy-caching foar URL's mei query-strings
Jou query-basearre boarnen in bewust cachebelied wylst har parameterwearden yn 'e cachesleutel bliuwe.
In query-string makket in respons net ûn-cachable ûnder moderne HTTP-regels. In iepenbiere boarne lykas /catalog?page=2 kin syn bedoelde farskens direkt ferklearje:
Cache-Control: public, max-age=60Dat is in foarbyldich belied foar iepenbiere ynhâld. De respons moat noch oan 'e oare easken foar cachableens foldwaan. Personalisearre resultaten soene gjin dielde caching krije moatte allinnich om't in proxy-operator in bettere hitrate wol.
De query bliuwt diel fan 'e doeldirekte URI dy't yn 'e cachesleutel brûkt wurdt. Side 2 en side 3 binne ferskate oanfregens. It fuortheljen fan 'e query om har URL's gelyk lykje te litten kin it iene resultaat foar it oare betsjinje; it makket de resultaten net gelykweardich.
HTTP's âldere beheining op heuristyske farskens foar query-URL's waard fuorthelle nei't bliek dat dy min útfierd wie. Eksplisite farskens foarkomt fertrouwen op in cache-skattin, wylst lokale proxy-regels noch hieltyd beskate URL's útslute kinne.
Gewoane HTTPS CONNECT-ferkear lit de boarne en syn cachebelied binnen TLS. De tunneljende foarútproxy kriget gjin objekteskach foar dy siden allinnich om't de URL in query brûkt.