Re: HTTP Caching Model?

In message <199412151233.HAA16375@ebt-inc.ebt.com>, Gavin Nicol writes:
>> URI-header      =       "URI" ":" 1#( URI [";" vary] )
>> vary            =       "vary" "=" <"> 1#vary-param <">
>> vary-param      =       "type" / "language" / "version" / "encoding"
>>                 /       extension-vary
>
>The language parameter should not be part of the spec. This assumes
>that a single document will contain a single language.

How so? I see no inconsistency between multi-language documents and a
language preference negociation.  Could you give an example of
problematic behaviour?

> In addition, I
>tend to think that any information that is available in multiple
>languages, will probably be stored as seperate files (or "documents"),
>and hence, would have different URI's. I do not think decisions can
>reasonably be made automatically at the protocol level.

Why not?

Here's an example: a certain European government agency is required
by law to make all its regulations and forms available in English,
French, and German.

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.

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.

But I don't see that having an Accept-Language negociation implies
that every entity has a unique Content-Language.


> They are
>rather, a navigational problem (and this might also be better handled
>at the markup level via the LANG element).

How would the LANG element contribute to a solution?


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.

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?

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.

Dan

Received on Thursday, 15 December 1994 09:29:52 UTC