1

In other questions, and in many places on the web, people note that browsers, IE especially, may cache Ajax requests in spite of headers to the contrary. The recommended fix is to add a timestamp or other "unique" field to each request, ensuring its uniqueness, and blocking caching.

My question is, should that always be in the query string? For GET requests, obviously yes, there's nowhere else it could go. But how about for POST requests, where there's both the query string (URL parameters) and a form body? Can you add a timestamp as a form field, or does it have to be in the URL/query string to have the desired effect?

How about raw JSON requests, where the post body itself is JSON, rather than form/url encoded name/value pairs? In that last case, the post body is binary. It seems unlikely that a timestamp within the post body would be noticed by any caching mechanism, and there's no form to attach it to, so that leaves the query string. Is cache-busting necessary in this case, or effective if done in the query string?

Community
  • 1
  • 1
enigment
  • 2,852
  • 7
  • 25
  • 29
  • I believe it should be part of the query in all cases. A different query (string) = a different resource = no caching, ever. –  Mar 09 '12 at 13:16
  • So different POST fields or field values != a different resource? Do raw JSON Ajax requests have the excessive caching problem in the first place? – enigment Mar 10 '12 at 11:36
  • I am not sure about caching and POST. The server can respond with a Not-Modified/ETAG, but the resource *is not* determined by the *contents* of the POST data. –  Mar 10 '12 at 20:20

0 Answers0