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 usefulAccept-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
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. TheAccept-Encoding
is useful; if the client saysAccept-Encoding: gzip,deflate
it means the client can do transparent decompression. But about the only use I could think of forAccept
is image and video formats e.g. to provide alternate for browsers that don't support sayimage/svg+xml
orvideo/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.