- From: Adrien de Croy <adrien@qbik.com>
- Date: Fri, 22 May 2009 14:14:35 +1200
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
thanks! So I presume apart from a possible 300 reponse, a cache or client could treat it just as an HTML page that comes back? In which case it begs the question why it needs to be defined in the spec, since without any definition of how a list of optional URIs could be presented, let alone automatically selected from by a client, we're not talking about something that needs to be covered in the spec. That's almost impossible, since the server would need to provide all information that the client may need to make a decision on. A simple list of URIs isn't going to cut it. Options for a page I would have thought would normally be covered in the design of a site as a disambiguation page or similar. So anyway I'll ignore its existence for now, except to cover status 300 (not cache it I guess else will need to cache status codes as well). I'm just re-writing our caching, and want to get it right. So I'm currently poring over the caching sections of 2616. Are the drafts for caching for 2616bis in a usable state for this or should I soldier on with 2616? Did we get anywhere with discussions about using the method as part of the cache key? I'm presuming this is a go, since other methods may have cacheable responses. regards Adrien Julian Reschke wrote: > Adrien de Croy wrote: >> >> Does this really exist? >> >> Apologies if this is covered elsewhere. >> ... > > I've seen servers respond with 300 (*) and multiple URIs in the > response body; but I'm not aware of any clients that automatically act > on the 300 status. > > BR, Julian > > (*) I think httpd does under the right circumstances > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Friday, 22 May 2009 02:12:05 UTC