W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

RE: service description discovery

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>
Message-Id: <1252928673.5765.43.camel@Kalb>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:08:28 GMT