Why doesn’t the HTML\DOM specification allow hyperlinks to set an accept header

historyhttpspecifications

The purpose of the Accept header from the client is to tell the server what kind of data it will accept as a response to its request. We can set this header in asynchronous HTTP calls in Javascript, but not in HTML.

For example, consider a link such as <a href="/some/resource">Get as CSV</a>. If an attribute like accept="text/csv" were allowed, and the browser interpreted that to send an Accept: text/csv header with that request, the server could respond to the semantics of the request. Without it, we might create a link such as <a href="/some/resource?format=csv">Get as CSV</a>, and the server must respond to the arbitrary query string parameter instead.

What are the reasons, both technical and historical, behind the HTML\DOM specification not allowing the setting of an Accept header through markup?

Best Answer

Because the headers are not part of the URL. The URL should identify the resource, on it's own, and should do it uniquely. The Accept (and the more useful Accept-Encoding) headers should not affect semantics of the request. They should indicate capabilities of the client so the server can format the response accordingly.

If you do a HTTP call from JavaScript, your JavaScript code is the client and so it gets to set headers. But for HTML link the browser is the client and therefore it gets to choose.

If you want to provide CSV to a user, the linked resource should generally be in a fixed format. Imagine the user does

Copy Link Address

$ wget PasteEnter

That's a legitimate thing for them to do for various reasons. And because the link promised them CSV, that's what they'll expect. But the wget won't get any other attribute of the link. Only the URL. So the information should be encoded in the URL.

In fact there are not many uses for Accept header, because most resources just have their format and don't make much sense in another. The Accept-Encoding is useful; if the client says Accept-Encoding: gzip,deflate it means the client can do transparent decompression. But about the only use I could think of for Accept is image and video formats e.g. to provide alternate for browsers that don't support say image/svg+xml or video/webm. Except browsers don't seem to actually advertise which media formats they support, so it does not work. And HTML chose to implement different, slightly more flexible mechanism anyway. And few other kinds of data have several widely implemented alternate formats to choose from.

Related Topic