From: Claes W. <kl...@gm...> - 2005-04-08 08:15:54
|
On Apr 7, 2005 11:42 PM, Vance Shipley <va...@mo...> wrote: > Klacke, > > It occurs to me that with the method I propose the server will > need to remember the resource variant descriptions. For example > out/1 returns: > > {alternates, [{"diagram.en.pdf", "0.9", [{type, "application/pdf"}, > {language, "en"}]}, > {"diagram.fr.pdf", "0.9", [{type, "application/pdf"}, > {language, "fr"}]}, > {"diagram.en.gif", "0.7", [{type, "application/pdf"}, > {language, "en"}]}, > {"diagram.fr.gif", "0.7", [{type, "application/pdf"}, > {language, "fr"}]}]} > > After negotiation a request will be made for one of these binary > files. Unless the server remembers the variant descriptions for > these resources it will have to fallback to some other method to > determine the appropriate Content-*: header fields. > This is possibly implementable in the server process. It needs experimentation, as well as deep understanding of how the content negotiation is really supposed to work. That the server needs to remember anything sounds as if it breaks the stateless-ness of HTTP, but I know to little (haven't yet even read the relevant parts from the rfc) abouth the HTTP content negotiation to say. The server process, which ships the {alternate, Alt} header, could remember this. Then it would be valid for that particular socket only, or does it have to be remembered for the "session" ? > What do you think? > I don't think anything at this stage :-) The question wether it has to be remebered for the session or just for a single socket, determines the implementation entirely. The concept of "session" is a bit muddy and is not at all part of HTTP (usually solved with server-side state and cookies) > In the Apache implementation the web author doesn't create the > Alternates: header directly as I propose but instead creates a > static file to define the Content-*: header fields for individual > URIs. Alternatively the server is left to decide based on matching > the file extensions. > /klacke |