What is the exact response structure for HTTP status code 300 (Multiple Choices)?

Question

When a user clicks a link to a drawing on my site http://mysite.com/some-drawing, I would like my server to respond with status code 300 and two resource locations: http://mysite.com/some-drawing.png and http://mysite.com/some-drawing.myapp, and have the client browser decide automatically which one to use, based on its capabilities:

• If MyApp is installed on the user's machine, then the browser should download the *.myapp version and use MyApp to display it.

• However, if MyApp is not installed, and the browser is incapable to display this version, then I would like it to pick the *.png version.

However, I am having a hard time figuring out the structure of a HTTP response with status code 300.

The rfc2616 says:

The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. 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.

If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.

The wording "entity containing a list of resource characteristics and location(s)" seems ambiguous. What does it mean? Does anybody know how this is done?

Answer 1

That won't work.

The "multiple choices" are done by sending the links in hypertext (HTML) content and let the user pick.

Answer 2

In theory, if a client supported server-driven negotiation, you could send back various 'Accept-*' headers, but those are rather limited (eg, Languauge, Encoding, Charset), and could be used for 'do you want the PDF or MS Word document?' or 'Would you like that in Spanish or English?'), but not for other arbitrary distinctions. I'm not aware of any browsers that support it. Instead, they have the browser send the Accept headers, and the server respond with whatever it thinks is best.

See :

• RFC 2295, "Transparent Content Negotiation in HTTP"
• RFC 2616, "HTTP/1.1" section 12 "Content Negotiation" (for problems related to server-driven content negotiation)

update :

Also see Mozilla Developer Network's "Content negotiation", which discusses some advantage and disadvantages of server-drive vs. client-driven negotiation, and some additional headers that may be of interest (eg, looking to see if the client sends 'Negotiate' to announce what it supports)