- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 08 Oct 2007 15:26:14 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: Ian Hickson <ian@hixie.ch>, public-appformats@w3.org
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. / Jonas
Received on Monday, 8 October 2007 22:27:35 UTC