OSAPI: GET request for a flavor by its bookmark link returns 300

Performing a GET request on an image using it's self and bookmark links should both return details for the expected image. However, making a GET request using a image's bookmark link is currently returning a 300 response. Here's an example of what I am seeing:
curl -i -H "X-Auth-Token: fe35da61-b2fa-4d85-9a1f-ee30d549e184" http://127.0.0.18774/dwalleck-project/images/3136e6d3-2020-4b8d-8133-7c3dd7f51866
{"choices": [{"status": "CURRENT", "media-types": [{"base": "application/xml", "type": "application/vnd.openstack.compute+xml;version=2"}, {"base": "application/json", "type": "application/vnd.openstack.compute+json;version=2"}], "id": "v2.0", "links": [{"href": "http://127.0.0.1:8774/v2/dwalleck-project/images/3136e6d3-2020-4b8d-8133-7c3dd7f51866", "rel": "self"}]}]}

What I expect would be:

{"image": {"status": "ACTIVE", "updated": "2011-12-26T14:18:13Z", "name": "test50322812090", "links": [{"href": "http://127.0.0.1:8774/v1.1/dwalleck-project/images/3136e6d3-2020-4b8d-8133-7c3dd7f51866", "rel": "self"}, {"href": "http://127.0.0.1:8774/dwalleck-project/images/3136e6d3-2020-4b8d-8133-7c3dd7f51866", "rel": "bookmark"}, {"href": "http://10.13.136.213:9292/dwalleck-project/images/3136e6d3-2020-4b8d-8133-7c3dd7f51866", "type": "application/vnd.openstack.image", "rel": "alternate"}], "created": "2011-12-26T14:16:26Z", "minDisk": 0, "server": {"id": "d486bffa-ac07-46c0-a010-b2ad454128ba", "links": [{"href": "http://127.0.0.1:8774/v1.1/servers/d486bffa-ac07-46c0-a010-b2ad454128ba", "rel": "self"}, {"href": "http://127.0.0.1:8774/servers/d486bffa-ac07-46c0-a010-b2ad454128ba", "rel": "bookmark"}]}, "progress": 100, "minRam": 0, "id": "3136e6d3-2020-4b8d-8133-7c3dd7f51866", "metadata": {"instance_uuid": "d486bffa-ac07-46c0-a010-b2ad454128ba", "metakey4": "metavalue4", "image_state": "creating", "user_id": "dwalleck", "metakey1": "metavalue1", "metakey2": "metavalue2", "instance_ref": "http://127.0.0.1:8774/v1.1/servers/d486bffa-ac07-46c0-a010-b2ad454128ba", "image_type": "snapshot", "metakey3": "metavalue3", "backup_type": null, "auto_disk_config": "None", "metakey0": "metavalue0", "os_type": "linux"}}}

In addition, it's curious is the link URL in the 300 response that has v2 as the version, not v1.1.

This is all expected behavior. Bookmark links are not supposed to have versions in the url, and therefore the user has to provide a version in the accept header. Additionally, v2 is accurate as v1.1 is now a legacy alias for v2.

Interesting. I realize the bookmark URL should not have a version (otherwise it wouldn't be useful), but the requirement of an accept header with version isn't documented. I'll open a bug with the docs team.