OPTIONS is necessary if you want to offer APIs that support CORS: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
OPTIONS is necessary if you want to offer APIs that support CORS: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
I've found that some of the URL security that people setup only apply to GET/POST, they're unaware of these other methods (TRACK? WTF?). As such, it's nice to have these off by default, and turn them on when needed. I saw a good note some time ago from people essentially stat'ing files they shouldn't have been able to see at all via OPTIONS or HEAD because they were secured against GET and POST only.
There is a nice discussion going below on whether you need these for AJAX, conditional gets, etc. If you need this enabled for AJAX, consider enabling it for the URL or directory where your AJAX interactions occur. I run a large wordpress site and haven't had issues with any of this.
This acts like HEAD if the resource has not been modified and like GET if it has.
In practice this seems to be the go-to technique for browsers as well.
I looked it up, though. It looks like you have to have an ETag to do a conditional GET, so browsers use HEAD if the original response (the cached one) didn't include one.
Nope, not the case. May I ask where you read that? It differs from my reading of RFC2616 and my experience.
If the server gave you an ETag though you're supposed to include it in future cache-conditional requests. Section 13.3.4 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...) describes the interaction between ETags and modification dates.
Am I correctly inferring that you need at least a Last-Modified in the response to do a cache-conditional request, though?
Edit: The difference is that Last-Modified allows clients to use a heuristic to determine if the response should be cached for a certain duration (unless explicit Cache-Control or Expires headers are used). The heuristic isn't specified, but a 10% fraction of Date - Last-Modified is suggested, and in fact, that is what e.g. Internet Explorer does.
Are there some situations where browsers use HEAD instead of conditional GET? Or is my understanding wrong?
Still, HEAD seems like it should generally be fairly safe, so not something i'd leap to block.