add "profile" HTTP preference

[dret]

as a way to negotiate and signal profiles in HTTP that is independent of a profile parameter supported by the media type, a profile HTTP preference (based on https://tools.ietf.org/html/rfc7240) would allow profiles to be better supported one the HTTP level. maybe @jasnell has comments on how appropriate that usage of RFC 7240 would be?

[dret]

there is a possible alternative approach, which is using dedicated profile negotiation header fields: https://github.com/ProfileNegotiation/I-D-Accept--Schema (by @larsgsvensson and @RubenVerborgh)

[dret]

still waiting for feedback from @jasnell, but for now assuming that a profile preference would be in line with the intention of the Prefer header field.

[jasnell]

Sorry @dret ! Just spotted this again! Yeah, I think that's fine

[dret]

On 2018-03-17 13:05, James M Snell wrote:

Sorry @dret https://github.com/dret ! Just spotted this again! Yeah, I think that's fine

that's good to hear, and thanks for your response!

[larsgsvensson]

If the client states a preference for a profile using the Prefer header, the server can answer with Preference-Appliedif it honours the preference, but what does it answer if it doesn't and anwers using another profile instead?

[dret]

@larsgsvensson: that would be the same as what happens if the server simply does not understand or ignore the Prefer header: the server does whatever it want to do. preferences are non-binding, and clients have to be prepared to see their preferences being ignored. https://tools.ietf.org/html/rfc7240#section-2 :

The Prefer request header field is used to indicate that particular server behaviors are preferred by the client but are not required for successful completion of the request. Prefer is similar in nature to the Expect header field with the exception that servers are allowed to ignore stated preferences.

[larsgsvensson]

@dret

that would be the same as what happens if the server simply does not understand or ignore the Prefer header: the server does whatever it want to do. preferences are non-binding, and clients have to be prepared to see their preferences being ignored.

OK, thanks. But then there is no way the client would know which profile the data conforms to, as opposed to e. g. media types where client can say Accept: application/ld+json and the server can answer Content-Type: text/html . Even if the client cannot handle that, at least it knows it has received somethin it cannot handle an can act accordingly instead of having to try out different profiles and eventually throw an UnknownProfileException.

[dret]

On 2018-03-23 11:44, Lars G. Svensson wrote:

OK, thanks. But then there is no way the client would know which profile the data conforms to, as opposed to e. g. media types where client can say |Accept: application/ld+json| and the server can answer 'Content-Type: text/html|.

there are several ways for the profile to be discoverable, the server can signal profiles in the usual way: it may add a profile link in the Link header field, it may use the profile parameter on the media type (if the media type supports that), or it may use in-band signals in the content itself (if the media type supports that).

Even if the client cannot handle that, at least it knows it has received somethin it cannot handle an can act accordingly instead of having to try out different profiles and eventually throw an|UnknownProfileException`.

profiles are nothing but hints. clients always have to make sure they can handle what they received. that's a general rule of web architecture beyond just profiles.

one principle of profiles is that clients can always safely fall back to media type semantics, if they don't support the profile (a podcast is a feed, so clients can always safely treat it as such). clients only working with a specific profile and having no idea what to do otherwise would be bad clients.