On Oct 9, 2007, at 01:26, Jonas Sicking wrote:
Henri Sivonen wrote:
Also note that the server can make the GET request be cached in
the browser which should make the overhead of a GET fairly low.
Actually, the HTTP-level cacheability of GET doesn't work here.
The POST request to the URI invalidates the cached GET response,
so when you are doing the next POST, the GET response should no
longer be in cache. (This is not currently true of Firefox, but
that's a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=327765 )
Therefore, with GET you'd need to maintain an access-control
method authorization cache independently of the HTTP caching of
the GET response. And at that point, you might as well maintain an
access-control method authorization cache for information obtained
via OPTIONS.
Hmm.. this is very interesting indeed. I don't really have an
opinion either way as I don't know the specifics of HTTP well
enough. Another option would be to simply state that the
implementation is allowed to ignore that rule for the POST/PUT/
DELETE request that is coming after the GET for this one case.
I think making an exception to HTTP caching in this case to make the
GET response stick against RFC 2616 rules would be a bad idea since
the Web app might well malfunction if subsequent non-access-control
GETs retrieved a stale resource representation from the cache (in
cases where the GET is really about getting the resource).
The HTTP rule that POST invalidates the cache is actually useful and
it is very frustrating to develop a Web app when the browser doesn't
invalidate the cache properly. If the app developer can't count on
cache consistency working, (s)he'll have to break HTTP caching
*altogether* by never GETting the same URI twice by appending salt
that the server ignores. This would, of course, defeat any access-
control caching as well, so driving app developers to do this would
be bad.
OTOH, if you meant that the cache should be flagged stale for all
subsequent GETs except access-control checks, then you'd effectively
be special-casing access-control GETs on the HTTP library level
instead of keeping a separate access control cache on the XHR level.
I don't see how that would be better.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
