Re: Question about Accept header and structured suffixes

(top posting because Gmail app, sorry)

The server is *allowed* to send whatever it wants. If you want to follow
strict conneg, though...

Speaking of, whatever happened to RFC 2295?

Matthew Kerwin

On 13 Sep. 2017 03:53, "Remy Lebeau" <> wrote:

"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.


Received on Tuesday, 12 September 2017 22:06:42 UTC