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
