"Roy T. Fielding" <fielding@liege.ICS.UCI.EDU> tastet:
...
> Filename conventions are irrelevant in HTTP. In order for your application
> to work correctly, it must obey the same constraints as any cache.
> That means the client must map URLs to responses, not filenames.
True. Hard problem to solve generaly though. Esp. if I want the copy
to be 'file:' browsable. I want everything to work :-)
Maybe I should just supply a perl script that can http serve the http
responses to a http browser the user uses, in my dreams :-)
> How the application stores things locally is application-dependent, but
> there are sufficient clues given by Content-Location and Vary such
> that it can indeed know whether or not negotiation was used.
Simplyfying my argument:
- The use if Content-Encoding when content negociation has taken place
(server mapping http://.../foo to http://.../foo.gz for example)
is good and requires no filetype heuristics in a automated client,
it will only need a simple decode/store cycle.
- Use of Content-Encoding in a reply where content-negociation has not
happened because there was a direct mapping from the requested object
into the servers object space is not useful, and making this practice
forbiden will break nothing, remove no functionality. If it is allowed
a automated client will need to use file name heuristics to determine
if content negociation has taken place or not, and based on this
determination decide on a file name for local storage.
To conclude: I think that the Content-Encoding header should only be
used when according to the http servers native type rules the encoding
of the served object is different from the requested object. I.e. when
the server object is at another place on the content-encoding axis
than the requested object.
For the current-widespread use of http this will not break anything, it
will simplify some things, and in the case of a totaly alien object store
we have no idea what will happen anyway, I think.
Regards,
Nicolai Langfeldt