profile in Accept header must be a quoted-string

[jdesrosiers]

I discovered recently that the usage of the profile Accept header extension
described in the documentation is not a valid accept header extension.

Content-Type: application/json; profile=/schema-for-this-data

The schema should be within quotes in order the valid.

Content-Type: application/json; profile="/schema-for-this-data"

This is how the Content-Type header is defined

Content-Type   = "Content-Type" ":" media-type

media-type     = type "/" subtype *( ";" parameter )
type           = token
subtype        = token

parameter      = attribute "=" value
attribute      = token
value          = token | quoted-string

token          = 1*<any CHAR except CTLs or separators>
separators     = "(" | ")" | "<" | ">" | "@"
               | "," | ";" | ":" | "\" | <">
               | "/" | "[" | "]" | "?" | "="
               | "{" | "}" | SP | HT

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6
http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2

Therefore, /schema-for-this-data is not a valid token because it contains a
/. It needs to be expressed as a quoted-string. This occurs anywhere
profile appears in the documentation.

[awwright]

Oh wow, I think I make this mistake even in my own code. Nice catch.

+1

[awwright]

@jdesrosiers Note that RFC2616 is no longer current, that's defined in RFC7230 now: http://httpwg.github.io/specs/rfc7230.html#rule.token.separators

[jdesrosiers]

Oops. I actually wrote this up a while back shortly before I learned about RFC7230. I was lazy and didn't think to update it when I recreated it for this pull request.

But, is it true that RFC2616 is not longer current? Everything I have found on RFC7230 seems to call it a "proposed standard" or it is on a "standards track". This leads me to believe that it is still a work in progress and is not official yet. In that case RFC2616 would still be current. I've heard others refer to RFC2616 as obsolete as well, so am I missing something? Or, are we all jumping the gun because we are excited about the update?

[awwright]

@jdesrosiers https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

The designations are... complex and often misleading. I'm not sure what the distinction is. But what's important is that RFC7230, RFC7231, etc list RFC2616 as "Obsolete" which means it's no longer relevant in any capacity. The original .txt is never changed once published (which was in 1999), but kept for historical purposes of course.

[jdesrosiers]

Thanks @ACubed. That blog post puts it in no uncertain terms. Given the author, I'm sure he knows what he's talking about, but I was hoping for something more official than a blog post.

[awwright]

@jdesrosiers The official word is going to be the publication of a new RFC that lists the old one as obsolete. e.g. RFC 7230 specifies "Obsoletes: 2145, 2616". An index of the obsoleted RFCs is maintained at rfc-editor.org too. Additionally, you can see the brown header (=obsolete) at the IETF website, along with published errata: https://tools.ietf.org/html/rfc2616

It's just little bit confusing, I didn't actually realize rfc-editor.org was official.

[jdesrosiers]

@ACubed Yes, it is confusing. Thanks for shedding some light on it for me.

[awwright]

Hmm, do we have a policy on trailing whitespace on otherwise empty lines?

[jdesrosiers]

I don't think there are any official policies at this point, but removing trailing whitespace is a pretty widely accepted practice.