Re: Question about Accept header and structured suffixes

"application/atom+xml" is not a sub-type of "application/xml", so the 
server would not be allowed to send "application/atom+xml" if the client 
accepts only "application/xml".

"application/atom+xml" is a sub-type of "application/atom".  Even if the 
client specified it accepts "application/atom", "application/atom+xml" 
is still a distinct media type and would not be acceptable.  Neither 
RFCs 2616 nor 7231 make any allowance for "+" sub-types, so my 
interpretation is that the client would have to state 
"application/atom+xml" specifically (or "application/*", or "*/*", or 
omit the "Accept" header) in order for the server to send 
"application/atom+xml".

Remy Lebeau
Lebeau Software

On 9/12/2017 10:23 AM, Jack Firth wrote:
> RFC 6838 Section 4.2.8 defines Structured Syntax Name Suffixes, 
> allowing types to use a +
> symbol to indicate they are subtypes of another media type such as 
> application/atom+xml and
> application/xml. How do subtypes interact with the Accept header? Is a 
> server allowed to
> respond to a request with Accept: application/xml with Content-Type: 
> application/atom+xml? I
> imagine many clients compare the returned content type with their 
> requested content type with
> a simple equality check, which would raise an error in this case. Is 
> that bad behavior on the
> part of the client? If not, how should a client indicate that it 
> accepts a media type and any subtype
> of that type?
>
> P.S. This is my first post to the ietf-http-wg list. If this is not 
> the appropriate place for such a
> question or there is some other issue with my post, please don't 
> hesitate to let me know.
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>  Virus-free. www.avg.com 
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>