On Mon, 26 Nov 2012 15:01:55 -0200, Ney André de Mello Zunino wrote:
> I had always assumed that the handling of encoding issues in the context
> of web applications should be a responsibility of the HTTP server.
Nope.
It's the responsibility of the person or people developing and operating
the website to make sure it happens correctly.
The web server doesn't parse content, it sends it. It can be configured
to server specified file extensions with a specified content type, but it
doesn't know if the file contents match the file extension. Occasionally
I come across misconfigured web servers that server images with the
incorrect image type, typically png as jpeg or jpg as gif, presumably
caused by copying and pasting bits of config by people who didn't really
understand what they were doing (ie human failure, not software failure)
although that hasn't happened recently - it may have been a couple of
years since I last observed it - so I guess software and config updates
may be resolving that particular issue.
When the server gets the content from another process, eg by running a php
script, then the php script could deliver (x)html, a compressed archive
file of some sort, some form of proprietary or open formatted document,
images, sound files, video etc. In such cases, it is ridiculous to expect
the web server to know what content to server for a php file, and the php
file should supply the relevant information.
So it varies, the server can make a best guess based on the file type,
which is usually fine for static content, but that will not always be
correct for dynamically generated content that is just being piped
through the server from some other application. Such external sources
really need to be able to take care of such notifications, because a
given url file extension may not always relate to a single unique content
type.
Rgds
Denis McMahon