Atom links should respect Accept header

[justinsb]

The atom links have a huge overhead. In a quick experiment with an instance listing, the response doubled in size vs if the atom links were not present. As the atom links seem to carry no extra information vs the IDs, they should be optional.

Further, per the Atom RFC (http://www.ietf.org/rfc/rfc4287), the correct Content-Type for atom links is application/atom+xml. As such, we should return atom links only if the user sends an Accept header including the content type "application/atom+xml" or "application/atom+json".

If the client does not send an atom content type, but instead specifies e.g. "Accept: application/json", then we must not return the Atom formatted information.

[Christopher MacGown (0x44)]

I can't reproduce this in Essex:

https://gist.github.com/51c9103a3d5d011ba4a1

[Christopher MacGown (0x44)]

Whoops, my apologies… I pasted that into the wrong bug.

[Christopher MacGown (0x44)]

Looks like the following patch will solve the reported problem… but it does break all the extant tests:

https://gist.github.com/abafb94d4e2f4d905b9d

[Doug Davis (dug)]

If I understand the bug, you want to only return the atom links if the Accept header of the
GET to an Instance contains app/atom+xml (or app/atom+json). If so, then I think there's a
problem with this because the Accept header of the GET to the Instance doesn't really
tell you what the client is expecting when they follow the atom link. For all we know the client
will do a GET to the atom link's href and include app/atom+xml in that GET request - we can't tell
from just the GET to the Instance.

If we really want to reduce the size of resources that are returned I would suggest that we
look at a new query parameter that specifically means "do not include hrefs" - e.g. ?noref
or something like that.

But perhaps I'm misunderstanding the bug.

[Tong Li (litong01)]

Currently when you send a request like this.

GET http://example.com:8774/v2/0ddd9584ce9141e582249cef3e934e15/servers HTTP/1.1
User-Agent: Fiddler
Host: example.com:8774
X-Auth-Token: 7fd5cd2c38674c0b9ff8249340060402
Accept: application/xml

you will get this.

<?xml version='1.0' encoding='UTF-8'?>
<servers xmlns:atom="http://www.w3.org/2005/Atom" xmlns="http://docs.openstack.org/compute/api/v1.1">
 <server name="myMachine2" id="5b66b7d5-264c-42b5-be17-6148bcd1ed5f">
  <atom:link href="http://example.com:8774/v2/0ddd9584ce9141e582249cef3e934e15/servers/5b66b7d5-264c-42b5-be17-6148bcd1ed5f" rel="self"/>
  <atom:link href="http://example.com:8774/0ddd9584ce9141e582249cef3e934e15/servers/5b66b7d5-264c-42b5-be17-6148bcd1ed5f" rel="bookmark"/>
 </server>
 <server name="myMachine1" id="8e809e9a-62d8-48db-a330-cc4c9be968d0">
  <atom:link href="http://example.com:8774/v2/0ddd9584ce9141e582249cef3e934e15/servers/8e809e9a-62d8-48db-a330-cc4c9be968d0" rel="self"/>
  <atom:link href="http://example.com:8774/0ddd9584ce9141e582249cef3e934e15/servers/8e809e9a-62d8-48db-a330-cc4c9be968d0" rel="bookmark"/>
 </server>
</servers>

Do you want to get the following behavior instead?

GET http://example.com:8774/v2/0ddd9584ce9141e582249cef3e934e15/images HTTP/1.1
User-Agent: Fiddler
Host: example.com:8774
X-Auth-Token: 7fd5cd2c38674c0b9ff8249340060402
Accept: application/xml

response:
<?xml version='1.0' encoding='UTF-8'?>
<servers xmlns="http://docs.openstack.org/compute/api/v1.1">
 <server name="myMachine2" id="5b66b7d5-264c-42b5-be17-6148bcd1ed5f">
  <link href="http://example.com:8774/v2/0ddd9584ce9141e582249cef3e934e15/servers/5b66b7d5-264c-42b5-be17-6148bcd1ed5f" rel="self"/>
  <link href="http://example.com:8774/0ddd9584ce9141e582249cef3e934e15/servers/5b66b7d5-264c-42b5-be17-6148bcd1ed5f" rel="bookmark"/>
 </server>
 <server name="myMachine1" id="8e809e9a-62d8-48db-a330-cc4c9be968d0">
  <link href="http://example.com:8774/v2/0ddd9584ce9141e582249cef3e934e15/servers/8e809e9a-62d8-48db-a330-cc4c9be968d0" rel="self"/>
  <link href="http://example.com:8774/0ddd9584ce9141e582249cef3e934e15/servers/8e809e9a-62d8-48db-a330-cc4c9be968d0" rel="bookmark"/>
 </server>
</servers>

When you have this request

GET http://example.com:8774/v2/0ddd9584ce9141e582249cef3e934e15/servers HTTP/1.1
User-Agent: Fiddler
Host: example.com:8774
X-Auth-Token: 7fd5cd2c38674c0b9ff8249340060402
Accept: application/atom+xml

Then the response will be the same as what it is now?

If I guessed your intention right, then the difference is rather small. Unless you want all the links to be removed, in that case, I would think the response will miss information.

[justinsb (justin-fathomdb)]

According to the standard, links should only be present when the type is app/atom+xml or app/atom+json.

The links are redundant information; they can trivially be inferred from the url and the id. Further, I believe that the links don't include the version, and thus the link URL is invalid as provided.

In short, these links are:
 (1) a lot of overhead
 (2) superfluous
 (3) incorrect according to the standard
 (4) incorrect because of the version problem.

Some people might want atom links, but we should not return such an flawed response unless it is explicitly requested using the correct Accept header.

[Doug Davis (dug)]

Which standard are you referring to? If you mean the Atom standard
then I don't think it applies since Atom doesn't control what we return
for a GET to an Instance - that's under our control as its defined by
our docs not the Atom standard. The other, kind of interesting, aspect
is that if you look at the xml snippets that Tong pasted, the <link>
elements are not in the Atom namespace. Which, to me, means
they're not Atom links - they're just links that might share similar
semantics and syntax with atom:links. But, w/o them being in the
atom namespace, Atom has no control over them. Is it a bug
that they're not in the atom namespace?

I can't comment on whether they're needed or not, but unless we
remove them entirely from the representation of an Instance
(Vish?) I would think the best path for optionally excluding them
would be to base it on some flag other than the Accept header -
like a new query param as I suggested above.

[Doug Davis (dug)]

oops- for some reason when I looked before the "atom:" didn't appear - now they do.
Ignore my comment about them not being the Atom namespace. The rest of
my comments apply though. Weird. Maybe I need some sleep :-)

[Joe Gordon (jogo)]

we are dropping XML support in nova in Juno