cc'ing ALTO as Vijay suggested. Ben On 2 May 2012, at 20:24, Ben Niven-Jenkins wrote:
> Rich, Ted, > > On 2 May 2012, at 18:49, Richard Alimi wrote: > >> On Wed, May 2, 2012 at 10:39 AM, Ben Niven-Jenkins >> <[email protected]> wrote: >>> >>> On 2 May 2012, at 17:28, Ted Hardie wrote: >>>> >>>> It is not the cacheability of the results of post request that I was >>>> referring to, but >>>> the cacheability of the results of a 303. >>> >>> Ah, I see. Yes I see your issue with the text now. >>> >>> I believe there is an implicit assumption on the part of the authors that >>> in this model (receive a POST and return a 303) that the ALTO server could >>> be doing some level of "ALTO-application level caching" to avoid repeating >>> expensive queries by determining that a given POST would execute the same >>> query as a previous POST and therefore rather than run the query again, >>> just return a 303 to a resource on the ALTO server that contains the >>> results of the previous (identical) query. >>> >> >> The word 'caching' was meant to apply to the response the ALTO Client >> that actually contained the data it was looking for (that is, the >> following GET). An ALTO Server could also internally cache the >> results to avoid repeated computation, but that was meant to be >> implicit since this text was referring to the protocol messaging. >> >> I understand Ted's point about the ambiguity in the text 'employ >> caching for the response to a POST request'. We can clean that up to >> indicate that the caching is for the ALTO-level response (as returned >> by the following GET) and not the response to the POST itself. >> >>> But as I'm not an author I'll crawl back under my rock now. >> >> No - come back! :) > > As you asked so nicely, I wonder if the following (slightly wordy) change > would address Ted's comment: > > OLD: > Note that it is possible for an ALTO Server to employ caching for the > response to a POST request. This can be accomplished by returning an > HTTP 303 status code ("See Other") indicating to the ALTO Client that > the resulting Cost Map is available via a GET request to an alternate > URL (which may be cached). > NEW: > Note that it is possible for an ALTO Server to leverage caching HTTP > intermediaries for responses to both GET and POST requests by including > explicit freshness information (see Section 2.3.1 of [HTTPBIS Part6]). > > Caching of POST requests is not widely implemented by HTTP intermediaries, > however an alternative approach is for an ALTO Server, in response to POST > requests, to return an HTTP 303 status code ("See Other") indicating to the > ALTO Client that the resulting Cost Map is available via a GET request to an > alternate URL. HTTP intermediaries that do not support caching of POST > requests could then cache the response to the GET request from the ALTO > Client following the alternate URL in the 303 response (if the response to > the subsequent GET request contains explicit freshness information). > END > > Ted went on to say: >> Since cachability >> is a major reason cited for the re-use of HTTP, some additional text >> on the use cache control directives ("public" and "Max-age" seem >> particularly important in this context) might also be useful. > > I wonder whether a reference to Section 3.2 of HTTPBIS Part6 would suffice? > > Ben > > _______________________________________________ > apps-discuss mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
