Swift is a *server*; the *client* (whether python-swiftclient, a
browser, cURL, or some other HTTP client) is the user agent.
The note is clarifying that the client *should not assume that its
Accept header was respected*. Instead, it should inspect the headers
of the response (in particular, the Content-Type, Content-Encoding,
and Content-Language headers) to determine whether the response is
actually something it can handle. This reflects the server behavior
specified in the Accept header definition [1] (note the use of SHOULD
rather than MUST):
> If an Accept header field is present, and if the server cannot send
> a response which is acceptable according to the combined Accept
> field value, then the server SHOULD send a 406 (not acceptable)
> response.
RFC 7231 walks this back even further and explicitly lets the server
choose whether to respect the header [2]:
> If the header field is present in a request and none of the
> available representations for the response have a media type that
> is listed as acceptable, the origin server can either honor the
> header field by sending a 406 (Not Acceptable) response or disregard
> the header field by treating the response as if it is not subject
> to content negotiation.
So, the client (in this case, cURL) is misbehaving by sending a
q value with more than 3 decimal points. If we take a rather narrow
reading of the RFC, we've got two options: 400 because of the bad
header, or ignore the header entirely. A 406 would be inappropriate;
the problem is not that the server lacks an acceptable representation,
but rather that the client sent a malformed header. Swift is liberal
in what it accepts and takes a third option: as long as we can make
sense of the value, do what the client seemed to want.
That said, I think there *is* a valid (if low-priority) bug in
swob: any failure to parse the Accept header results in a 406,
even when a 400 may be more appropriate. In particular, when
performing an account or container listing, both
Accept: text/xml;q=foo
and
Accept: text/xml;q=0.8;q=0.5
...trigger a 406, despite the fact that Swift can send a text/xml
response.
Swift is a *server*; the *client* (whether python-swiftclient, a
browser, cURL, or some other HTTP client) is the user agent.
The note is clarifying that the client *should not assume that its
Accept header was respected*. Instead, it should inspect the headers
of the response (in particular, the Content-Type, Content-Encoding,
and Content-Language headers) to determine whether the response is
actually something it can handle. This reflects the server behavior
specified in the Accept header definition [1] (note the use of SHOULD
rather than MUST):
> If an Accept header field is present, and if the server cannot send
> a response which is acceptable according to the combined Accept
> field value, then the server SHOULD send a 406 (not acceptable)
> response.
RFC 7231 walks this back even further and explicitly lets the server
choose whether to respect the header [2]:
> If the header field is present in a request and none of the
> available representations for the response have a media type that
> is listed as acceptable, the origin server can either honor the
> header field by sending a 406 (Not Acceptable) response or disregard
> the header field by treating the response as if it is not subject
> to content negotiation.
So, the client (in this case, cURL) is misbehaving by sending a
q value with more than 3 decimal points. If we take a rather narrow
reading of the RFC, we've got two options: 400 because of the bad
header, or ignore the header entirely. A 406 would be inappropriate;
the problem is not that the server lacks an acceptable representation,
but rather that the client sent a malformed header. Swift is liberal
in what it accepts and takes a third option: as long as we can make
sense of the value, do what the client seemed to want.
That said, I think there *is* a valid (if low-priority) bug in
swob: any failure to parse the Accept header results in a 406,
even when a 400 may be more appropriate. In particular, when
performing an account or container listing, both
Accept: text/xml;q=foo
and
Accept: text/xml; q=0.8;q= 0.5
...trigger a 406, despite the fact that Swift can send a text/xml
response.
[1] http:// tools.ietf. org/html/ rfc2616# section- 14.1 tools.ietf. org/html/ rfc7231# section- 5.3.2
[2] http://