- From: Jacek Kopecky <jacek.kopecky@sti2.at>
- Date: Mon, 14 Sep 2009 13:44:33 +0200
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: Steve Harris <steve.harris@garlik.com>, "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Please also note the following:
>From Section 14.9.1:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
"""
By default, a response is cacheable if the requirements of the
request method, request header fields, and the response status
indicate that it is cacheable. Section 13.4 summarizes these
defaults for cacheability. The following Cache-Control response
directives allow an origin server to override the default
cacheability of a response:
public
Indicates that the response MAY be cached by any cache,
even if it would normally be non-cacheable or cacheable
only within a non- shared cache.
"""
I don't know which text is supposed to take precedence, but for example
Section 13.4 allows explicit cache control to override a MUST NOT cache
for status codes such as 302 and 307.
Jacek
On Mon, 2009-09-14 at 10:32 +0000, Seaborne, Andy wrote:
> > > option 2: don't see any particular issue here, but I'm wondering how
> > > easy is that, from a usual Web browser, to send that HTTP OPTION verb
> >
> > XMLHttpRequest supports it on all major browsers, the only real issue
> > is the caching situation.
>
> I checked and RFC 2616 says:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2
>
> """
> Responses to this method are not cacheable.
> """
>
> Andy
>
>
Received on Monday, 14 September 2009 11:45:12 UTC