- From: S. Mike Dierken <mdierken@hotmail.com>
- Date: Fri, 10 Jan 2003 18:11:02 -0800
- To: <www-talk@w3.org>
- Cc: <rest-discuss@yahoogroups.com>
----- Original Message ----- From: "Bjoern Hoehrmann" <derhoermi@gmx.net> > > See section 19.6.2.1 of RFC 2068, RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 19.6.2.1 Alternates The Alternates response-header field has been proposed as a means for the origin server to inform the client about other available representations of the requested resource, along with their distinguishing attributes, > section 8.3 of RFC 2295 and RFC 2295 - Transparent Content Negotiation in HTTP 8.3 Alternates The Alternates response header is used to convey the list of variants bound to a negotiable resource. This list can also include directives for any content negotiation process. If a response from a transparently negotiable resource includes an Alternates header, this header MUST contain the complete variant list bound to the negotiable resource > section 19.6.3 (last paragraph) of RFC 2616. RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 19.6.3 Changes from RFC 2068 The Alternates, Content-Version, Derived-From, Link, URI, Public and Content-Base header fields were defined in previous versions of this specification, but not commonly implemented. See RFC 2068. > There is no means I am aware of to > inform the client about acceptable media types for POST/PUT/... > requests, but a server will send status 415 if the request entity media > type is unsupported. Thanks for the info! Good stuff. If Alternates indicates the media type for a representation of a resource - and PUT will store that representation, while not explicit, it may make sense to try using Alternates as the acceptable format for a PUT. I'd rather have a more explicit mechanism though, since Alternates seems connected with GET.
Received on Friday, 10 January 2003 21:10:50 UTC