HTTP-proksiëkas vir URL's met navraagstringe

'n Navraagstring maak nie 'n antwoord onkasbaar onder moderne HTTP-reëls nie. 'n Openbare hulpbron soos /catalog?page=2 kan sy beoogde varsheid direk verklaar:

Cache-Control: public, max-age=60

Dit is 'n illustratiewe beleid vir openbare inhoud. Die antwoord moet steeds aan die ander kasbaarheidsvereistes voldoen. Gepersonaliseerde resultate behoort nie gedeelde kas te kry net omdat 'n proksibeheerder 'n beter trefsyfer wil hê nie.

Die navraag bly deel van die teiken-URI wat in die kassleutel gebruik word. Bladsy 2 en bladsy 3 is verskillende versoeke. Om die navraag te stroop sodat hul URL's eenders lyk, kan die een resultaat vir die ander lewer; dit maak die resultate nie gelykwaardig nie.

HTTP se ouer beperking op heuristiese varsheid vir navraag-URL's is verwyder nadat dit geblyk het swak geïmplementeer te word. Eksplisiete varsheid vermy om op 'n kas se raaiskoot te vertrou, terwyl plaaslike proksireëls steeds bepaalde URL's kan uitsluit.

Gewone HTTPS CONNECT-verkeer laat die hulpbron en sy kasbeleid binne TLS. Die tonnelende voorwaartse proksi kry nie 'n objekkas vir daardie bladsye nie bloot omdat die URL 'n navraag gebruik.