On Jan 26, 2009, at 10:47 PM, Gili wrote:
> Paul Sandoz (via Nabble) wrote:
> > On Jan 26, 2009, at 1:44 PM, Gili wrote:
> > My understanding is a 300 response is about *related
> representations*
> > not about related resources i.e. the former is more specific than
> the
> > latter, and i my assumption is your use-case fits into the latter
> > category. Is my assumption correct?
>
> Correct.
>
> > > Can you please give a concrete example of when a 300 response
> would be
> > > appropriate?
> > >
> >
> > A request to "/content" returns distinct URLs:
> >
> > /content.xml
> > /content.json
> >
> > Or returning the languages supported when the accept language header
> > is not supplied.
>
> How do 300 MULTIPLE_CHOICES and the Vary header relate to
> one another?
>
> 1) Can you give an example of how Vary can be used without 300
> MULTIPLE_CHOICES? Or are the two always used together?
>
AFAICT the HTTP spec says nothing specific about the use of Vary and
300 responses.
The response entity of a 300 response is cacheable. Perhaps this is
something that needs to be clarified? Perhaps you could ask here:
http://tools.ietf.org/wg/httpbis/
?
> 2) How can the server specify not just the names of the headers that
> may
> be manipulated (Accept*) but also the possible values?
>
> 3) If the user hits /content but doesn't specify Accept, how can 300
> MULTIPLE_CHOICES return a list of choices all having the same URL
> (i.e.
> /content) but with different Accept headers?
>
I think you may be referring to the specifics of the representation
returned. The spec states:
"The entity format is specified by the media type given in the
Content-Type header field. Depending upon the format and
the capabilities of the user agent, selection of the most
appropriate choice MAY be performed automatically. However, this
specification does not define any standard for such automatic
selection."
Nor does the specification define any standard for such entity formats.
Paul.