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

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

Ted,
On 26 Apr 2012, at 22:40, Ted Hardie wrote:
> In section 7.2.2, the document says:
> 
>   "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)."
> 
> The phrase "employ caching" is ambiguous here, as the results of the
> initial POST are not cacheable even in the case of a 303; only
> the results of the later GET request are cachable.

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

>  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.