Re: HTTP Caching Model?

> A client from France makes a request:
> 
> 	GET /forms/tax-form-1 HTTP/1.0
> 	Accept-Language: fr
> 
> And the server hands out the french version of the form.
> The alternative is the dreaded:
> 
> 	"Click _here_ for English"
> 	"Click _here_ for French"
> 	"Click _here_ for Spanish"
> 
> As this is not really current practice, I could live with leaving it
> out of the spec. But not because of the reasons you cite.

I would be very sad if we decide on taking it out. I have great plans
of implementing it in the next release of the Library. Imagine the
possibilities it gives when used in the line mode browser:

	www -language dk

It is definitely needed in this version of HTTP!

> If there is some place in the spec that says that every entity has a
> well-defined, unique Content-Language, that _is_ a bad thing and it
> should be fixed. The spec doesn't say anything like "The default
> Content-Language is English," does it?
>
> It could perhaps be made clearer, by saying something in 7.6 like
> 
> 	NOTE: In the absence of an explicit Content-Language header,
> 	the client should make no assumptions about the language of
> 	the returned entity, as it might be a language-neutral entity
> 	such as a graphic, or it might be a multi-language document.

You can have a list of multiple languages in the Content-Language for a
multi-linguistic document - or an audio file etc.

> By the way... is it a fault for a server to send an entity with a
> Content-Type not listed in the Accept: header of the request?
> Hmmm... the "406 None Acceptable" header seems to imply that it is.
> 
> Now that I think about it, it shouldn't be.

There are arguments for both views. If you have a dedicated client for
only a few content-types then you are not interested in anything you
don't ask for. However, general WWW clients might be able to handle
most formats so here it doesn't really matter.

> If a server has several representations of an object, it is bound to
> return one that minimizes the penalty function defined by the
> negociation algorithm. There may be a unique representation that
> minimizes the penalty, or there may be two or more that are equally,
> but minimally "bad." In that case, the server may return either of the
> equally bad representations.
>
> If a client accepts only HTML, and the server has only postscript, then
> the postscript representation does in fact minimize the penalty function,
> and the server may return that representation, no?
> 
> I believe this matches current practice. Has anybody done any testing
> on this?

This _is_ current practice but the server _must_ have the possibility
of not sending the object, that is "406 None Acceptable", as the client
very easy can specify that it accepts all formats by using "Accept: */*"

> Perhaps there should be a new header, say "Max-Penalty." The
> interaction is similar to the If-Modified-Since header: the client
> gives a maximum tolerable value for the penalty function. If all
> representations exceed that maximum, then the server responds with:
> 
> 	406 No suitable representation
> 
> This would require that the actual calculation of the penalty function
> -- rather than just its general properties -- be specified in the
> protocol.

In theory this is a good idea, but in practice it will never be
possible to standardize the quality factor in terms of absolute values
as the client does not know the server values. The q factores are only
valid as long as they are relative to each other.

-- cheers --

Henrik

Received on Thursday, 15 December 1994 10:49:11 UTC