On Wed, May 2, 2012 at 12:29 PM, Ben Niven-Jenkins
<[email protected]> wrote:
> 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
This seems reasonable to me, except would it be appropriate to have
this kind of document dependency? Would it be more appropriate to
just reference RFC2616?
>>
>> 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?
Once upon a time, we used to have more detail about how to use HTTP
(caching in particular) in the ALTO Protocol draft itself. The
recommendation at that point was to strip out the large majority of it
and rely on the reference to the HTTP specs being sufficient.
That said, any pointers to help out implementers are fine with me as
long as we don't to back to where we were before :) A concise hint or
direct reference pointing to the cache control directives seems
reasonable to me unless there are objections.
Thanks for the feedback,
Rich
>>
>> 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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
