Wandering Thoughts archives

2008-01-06

Why the server is the right place to determine web content types

There are two parties that could be responsible for determining what type of content you are getting in a HTTP response, whether the data is HTML or a PDF or a JPEG or so on: the server or the client. The web has opted to make it determined by the server, and this is the correct place for a simple reason: consistency.

Imagine a world where the clients determine what the content type is. If there is no standard for how clients determine the content type, the consistency problems are obvious; the interpretation of your content is at the mercy of the various different content sniffing algorithms of all of the clients out there in the field, and worse, you have no convincing argument that any particular client is incorrect. Introducing new content types is hell, because you have to design every new type format so that it cannot possibly be interpreted (by any client) as some other undesirable content type.

(The inevitable result is that everyone spends a great deal of time reverse engineering the content sniffing algorithms of first Netscape and then IE, and perhaps someone patents some of the especially good bits.)

If you have a clear standard but it's possible for the same chunk of data to validly be several different content types, you cannot publish arbitrary documents and be sure of how they will be interpreted (without running the standard content sniffing algorithm against them and discovering that clients will see your X as a Y). You also have much the same problem with introducing new content types as before.

If you have a clear standard and it is impossible for one document to validly be of more than one content type, congratulations; you have recreated an awkward version of server side Content-Type: MIME headers, except built in to all of the clients and thus subject to all of their bugs. And you still have serious issues adding new content types.

Regardless of its problems, the advantage of the server sending the content type is that it is unambiguous and thus consistent; every client is sure to see the same view of the content, and if something goes wrong is it clear who is at fault (depending on what went wrong). It is also much easier to upgrade things incrementally, because at least in theory you can be sure that no one changes their view of old content and that everyone will have the correct view of the new content.

(And if any client deviates from this in practice, it is clearly at their own risk and their own fault.)

Or to put it another way: the server determining content type is safer than the clients doing it because only one program (the server) has to get it right, instead of lots of programs (all of the clients).

(And if something goes wrong it does so all the time and in an obvious way.)

web/WhyServerContentType written at 23:43:06; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.