Hi, Am Sonntag, den 18.11.2007, 16:01 +0100 schrieb David Nuescheler: > I noticed that the resolution for scripts in microsling is based on > the mime-type > and not how I would have expected based on the extension.
Actually, the resolution is based on the request url extension, only that there is some kind of an indirection, others call this abstraction :-) The problem is, that the extension is not all the times unique. For example, there are people using .htm and others that are using .html but all of them mean text/html. So instead of requiring two scripts for .htm and .html, we just require html (for text/html). It gets of course more interesting in the case where there is no request extension: What script should we select ? Currently, we default to text/plain, which is probably not the correct solution. > I think that the additional indirection to go through a mime-type table adds > complexity (since it is yet another mechanism) and is questionable to begin > with since somehow it seems to tie the response mime-type into the request > behaviour for no apparent reason. In fact there is one reason, and I think this reason validates it all: The client tells by means of the request, what he or she expects. So in the same way as the request URL indicates the desired content to be delivered, the response mime-type is derived from (a) the client request URL and (b) to the HTTP Accept header (not implemented in microsling, yet to be done in Sling) to indicate the expected response content type. This is no tie-in, just trying to meet up with the client's expectation. > I know of a lot of cases where the > same response script offers responses in various (not limited) mime-types, > based on what the user uploaded to the repository. Well, this is a delicate issue: If as a client I request something with extension .txt I do expect a plain text response and not a GIF and I do absolutely not care what some other guy might have stored in the repository. If of course there is not plain text representation of the addressed content, I would expect an appropriate HTTP status code. Hope, this makes my case clear for using the response content type for the script resolution, whereas the response content type is derived from the request extension (and in Sling in the future probably also from the Accept HTTP header). Regards Felix
