W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: 12.2. Agent-driven negotiation

From: Adrien de Croy <adrien@qbik.com>
Date: Fri, 22 May 2009 14:14:35 +1200
Message-ID: <4A160A8B.1030207@qbik.com>
To: Julian Reschke <julian.reschke@gmx.de>
CC: HTTP Working Group <ietf-http-wg@w3.org>


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.



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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:49 UTC