300（多选择）状态码表明目标资源有超过一个表示，每个表示有它自己更具体的标识符，并且选择信息正被提供，用户（或用户代理）可以通过重定向到它请求的这些标识符的一个或多个选择一个表示。换句话说，服务器期望用户代理参与被动协商以选择对它的需要最合适的表示（3.4节）。

    如果服务器有一个首选选择，服务器应该生成一个包含首选选择的URI引用的Location头字段。用户代理可能使用Location字段值自动重定向。

    对于不是HEAD的请求方法，服务器应该在300响应中生成一个负载体，它包含表示元数据和的列表和用户或用户代理可能选择的最优选的一个URI的引用。用户代理可能自动的从那个例表中做出一个选择，如果它理解被提供的媒体类型。用于自动选择的具体的格式没有在本协议中定义，因为HTTP试图与它的负载的定义保持正交。实践中，该表示以被认为是用户代理可接受的一些容易解析的格式来提供，如通过共享设计或内容协商所确定的，或以一些通常接受的超文本格式来确定。

    300响应默认是可缓存的；即除非方法语义表明不可缓存或带有明确的缓存控制（查看你RFC7234，4.2.2节）。

    注意：对300状态码的原始提案定义了URI头字段以提供一个可选表示的列表，这样它对于200，300和406响应将可用并且在HEAD方法的响应中被传递。然而部署的缺乏和语法上的分歧导致了URI和Alternates（一个子提案）从本规范丢弃。可以使用一组Link头字段（RFC5998）来传达列表，每一个都有一个“备选”关系，虽然部署是一个鸡蛋与鸡的问题。