Какова структура ответа для кода статуса HTTP 300 (множественный выбор)?

Question

Когда пользователь нажимает на ссылку на рисунок на моем сайте http://mysite.com/some-drawing, Я бы хотел, чтобы мой сервер ответил кодом статуса 300 и двумя локациями ресурсов: http://mysite.com/some-drawing.png и http://mysite.com/some-drawing.myapp, и чтобы клиентский браузер автоматически определял, какой из них использовать на основе по своим возможностям:

• Если MyApp установлен на компьютере пользователя, то браузер должен загрузить версию *.myapp и использовать MyApp для его отображения.

• Однако, если MyApp не установлен, и браузер не может отобразить эту версию, то я бы хотел, чтобы он выбрал версию *.png.

Однако, я с трудом выяснить структуру ответа HTTP с кодом состояния 300.

rfc2616 говорит:

Запрошенный ресурс соответствует любому из набор представлений, каждый со своим конкретным местоположением, и агент- управляемая информация о переговорах (раздел 12) предоставляется так, что пользователь (или пользовательский агент) может выбрать предпочтительное представление и перенаправить запрос на это место.

Если это был не запрос HEAD, ответ ДОЛЖЕН содержать объект , содержащий список характеристик и адресов (ов) из которых пользователь или агент пользователя может выбрать один наиболее подходящий. Формат объекта задается типом носителя, указанным в поле заголовка Content- . В зависимости от формата и возможностей пользовательский агент, выбор наиболее подходящего варианта может быть выполнен автоматически. Однако эта спецификация не определяет любой стандарт для такого автоматического выбора.

Если у сервера есть предпочтительный выбор представления, он ДОЛЖЕН включать конкретный URI для этого представления в поле ; пользовательские агенты МОГУТ использовать значение поля Location для автоматического перенаправления . Этот ответ можно кэшировать, если не указано иное.

Формулировка «объект, содержащий список характеристик и местоположения (ов)» кажется неоднозначным. Что это значит? Кто-нибудь знает, как это делается?

Answer 1

Это не сработает.

«Несколько вариантов» осуществляется путем отправки ссылок в гипертекстовом (HTML) контенте и позволяет пользователю выбрать.

Answer 2

Теоретически, если клиент поддерживал ведение переговоров с сервером, вы можете отправлять различные заголовки «Accept- *», но они довольно ограничены (например, «Лангеография», «Кодировка», «Charset») и могут использоваться для «do вам нужен документ PDF или MS Word? " или «Хотите, чтобы это было на испанском или английском?»), но не для других произвольных различий. Я не знаю обо всех браузерах, которые его поддерживают.Вместо этого у них есть браузер, отправляющий заголовки Accept, и сервер отвечает тем, что, по его мнению, является лучшим.

См:

• RFC 2295, "Transparent Content Negotiation in HTTP"
• RFC 2616, "HTTP/1.1" section 12 "Content Negotiation" (для проблем, связанных с серверным приводом содержания переговоров)

обновления:

Также см Mozilla Developer Network's "Content negotiation", которая обсуждает некоторые преимущества и недостатки сервера-диска против кли nt-ориентированное согласование и некоторые дополнительные заголовки, которые могут представлять интерес (например, глядя, хочет ли клиент отправлять «Negotiate», чтобы объявить, что он поддерживает)