Discuss rel="alternate" approach to preemptive content negotation

[BigBlueHat]

First merged, and then discussed in this PR #133

Adding on behalf of @pchampin's concerns on the PR.

[iherman]

@BigBlueHat, just to avoid going back and forth between two issues, I guess this is the issue you are referring to:

What I mentioned on the call Friday was that the only definition of rel="alternate" (that I'm aware of) is in https://html.spec.whatwg.org/multipage/links.html#rel-alternate
What I mentioned on the call Friday was that the only definition of rel="alternate" (that I'm aware of) is in https://html.spec.whatwg.org/multipage/links.html#rel-alternate

The summary definition is "Gives alternate representations of the current document." but the follow-on expansion on it includes "The meaning of this keyword depends on the values of the other attributes."

The examples in that section include alternate CSS styles (i.e. rel="alternate stylesheet"), Atom/RSS alternate representations (i.e. rel="alternate" type=""), and using it for language [content] negotiation (i.e. rel="alternate" hreflang="" +/- type="").

So, using alternate here to accomplish a pre-flight content negotiation (of sorts) is not without its precedence conceptually. However, none of that directly answers the base URI situation...as in the closest experiential case (language negotiation) the browser would navigate to the new resource based on language preferences--thereby acting more like a 30* redirect than like content negotiation.

See #133 (comment)

[iherman]

Just a side remark on the above:

On the call we made a strict separation (after a while:-) between the usage of the <link> element and the headers of an HTTP return. My understanding is that this issue, and the PR, was strictly on the latter.

We are a (somewhat unfortunate) situation that there is an HTTP link alternate specification that indeed refers to (in https://www.iana.org/assignments/link-relations/link-relations.xhtml) to the HTML specification above, which blurs the differences between HTTP and the HTML usage; clearly, for the former, the remark

"The meaning of this keyword depends on the values of the other attributes."

is not relevant...

Based on all this, to be honest I am not sure at this point what is exactly the issue we are discussing...

[pchampin]

According to RFC8288#appendix-A, the Link HTTP header and the <link> HTML element are just two serializations of the same concept. So I do not have a problem with the fact that rel="alternate" is defined in the HTML spec even if we want to use it in HTTP.

Actually, I now realize that my comment was on the wrong part of the patch ! 8-(
It should have been about line 5833. It might explain the long thread if we are not arguing all arguing about the same thing !...

I'm really sorry for wasting your time. I'll open a new issue (#139) with a more explicit subject and a correct pointer...