Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt

[Ben Niven-Jenkins <[e-mail]>]

Rich, Ted,

On 2 May 2012, at 18:49, Richard Alimi wrote:

> On Wed, May 2, 2012 at 10:39 AM, Ben Niven-Jenkins
> <[e-mail]> 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