Accept should reflect what the UA accepts, not what the page says the server provides.

Ian that would appear to be incorrect given that, according to the HTTP spec, the Accept header is simply intended to indicate the appropriate media types for a response to a given request:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

"The Accept request-header field can be used to specify certain media types which are acceptable for the response"

So, the value of the Accept header should be taken (if specified) from the type attribute for a given hyperlink element - which is presumably why firefox modifies the accept header for the style and script elements.

This allows hyperlinks to specific representations that must be negotiated via HTTP content negotiation - as it stands, it is not possible to specify such a link with HTML5.

i.e. currently - these links would actually generate identical requests with the same Accept header: 

<a type='application/xml' href='/document'>document in xml</a>
<a type='application/json' href='/document'>document in json</a>

If implemented any existing mechanisms which disregard the Accept header would remain unaffected by the change. 

If no type is specified then default UA Accept header value should be assumed.

HTTP is written with the assumption that client headers are set by the client, not set by an agent of the server (such as the Web content).

If you disagree with this interpretation of the HTTP spec, then please escalate this to the chairs.

(In reply to comment #3)
> HTTP is written with the assumption that client headers are set by the client,
> not set by an agent of the server (such as the Web content).
> 
> If you disagree with this interpretation of the HTTP spec, then please escalate
> this to the chairs.

In this proposal there would be nothing which prevents a client completely ignoring the guidance of the type attribute - it should be best practice to follow the type attribute this way, but not mandatory.

Also if the UA does not support the media type(s) specified for the link, it can opt to not make the request or make it and revert to its default Accept header.

Either way - it is the client which is ultimately controlling the header.

How the client uses the a[type] attribute is up to them, as the type attribute is "purely advisory".  Using the type attribute in the way you've outlined is permitted by the existing specification.  Your example does not suggest any additional constraints, only suggesting best practice.  

While it may be good practice for a client to use the a[type] in the request header, I can see how that implementation detail probably does not belong in the HTML language specification.

(In reply to comment #5)
> How the client uses the a[type] attribute is up to them, as the type attribute
> is "purely advisory".  Using the type attribute in the way you've outlined is
> permitted by the existing specification.  Your example does not suggest any
> additional constraints, only suggesting best practice.  
> 
> While it may be good practice for a client to use the a[type] in the request
> header, I can see how that implementation detail probably does not belong in
> the HTML language specification.

These mechanisms are impractical unless there is consensus among major clients. 

Is the HTML spec not the best place to define a 'good practice' interpretation of the attribute's significance within a hyperlink?

*** Bug 8797 has been marked as a duplicate of this bug. ***

Ian, please could we continue this discussion - as your responses so far haven't cleared this up for me.

There are already a couple of examples of HTML requiring that the client alter certain headers when sending subsequent requests:


1. HTML5's rel=noreferrer says that "the user agent must not include a Referer (sic) HTTP header (or equivalent for other protocols) in the request."

http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer

Note that it even says "must", whereas the proposal in this ticket could presumably be phrased as a suggestion, not a requirement.


2. <form enctype="...">

http://www.w3.org/TR/html401/interact/forms.html#adef-enctype

This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.