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

[Richard Alimi <[e-mail]>]

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:
>
>> On Wed, May 2, 2012 at 9:23 AM, Ben Niven-Jenkins
>> <[e-mail]> wrote:
>>> Ted,
>>
>>> I do not believe that this is the case, from Section 6.5 of draft-ietf-httpbis-p2-semantics-19 (RFC2616 has similar text to the first paragraph):
>>>
>>>   Responses to POST requests are only cacheable when they include
>>>   explicit freshness information (see Section 2.3.1 of [Part6]).  A
>>>   cached POST response with a Content-Location header field (see
>>>   Section 6.7 of [Part3]) whose value is the effective Request URI MAY
>>>   be used to satisfy subsequent GET and HEAD requests.
>>>
>>>   Note that POST caching is not widely implemented.  However, the 303
>>>   (See Other) response can be used to direct the user agent to retrieve
>>>   a cacheable resource.
>>>
>>> Ben
>>
>> 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! :)

Rich

>
> Ben
>
>>  See 10.3.4 of RFC 2616:
>>
>> The 303 response MUST NOT be cached, but the response to the second
>> (redirected) request might be cacheable.
>>
>> regards,
>>
>> Ted Hardie
>