- From: Yves Lafon <ylafon@w3.org>
- Date: Wed, 19 Nov 2003 03:13:54 +0100 (MET)
- To: Mark Nottingham <mark.nottingham@bea.com>
- Cc: Martin Gudgin <mgudgin@microsoft.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
On Tue, 18 Nov 2003, Mark Nottingham wrote: > > of headers continuation, implicit LWS, implementation that are not > > accepting reformatting of some headers will surface because of this use > > case. > > Are you thinking specifically of cookies? Perhaps it would be best to > just recreate the headers line-for-line without any combination or > whitespace folding (except perhaps for newlines), and just the escaping > necessary to make it legal XML... The problematic implementation are of the cookie header, mainly, but odds are low that we will have to "cache" them. wrt to recreation/reformatting of headers, we should stick to what rfc2616 says for intermediaries. > > Also, in the case of UC2 and HTTP resources, how will we handle the > > content negotiation case if the sender embeds a format that the > > receiver > > can't understand, but with a Vary header, should we require all > > implementation that use this deferenciation scheme to act as fully > > compliant HTTP/1.1 caches? > > Hmm. Vary is part of a protocol sequence (Accept-* on the request, Vary > on the response; Mogul calls it a "variant-header", RFC2616 calls it a > "response header", but neither classification seems vary satisfying in > this context), so it's difficult to specify how to use it. My view of Vary is a bit different, as I always considered URIs subject to negotiation to be first class object with the semantic of dispatching to the most relevant resource, so Vary just means "I can forward the processing of your HTTP verb to other ones that may be more suited" > In other words, understanding Vary presumes that the client (whether > the original requester or a subsequent client hitting a cache) has > expressed its preferences to the server; in a standalone SOAP message, > these aren't known at time of its creation. The relevant portion of > 2616 is in section 13.6: Well, if we have to embed a representation in the message, then the originator of the SOAP message has to access the resource with its own preferences > > When the cache receives a subsequent request whose Request-URI > > specifies one or more cache entries including a Vary header field, > > the cache MUST NOT use such a cache entry to construct a response to > > the new request unless all of the selecting request-headers present > > in the new request match the corresponding stored request-headers in > > the original request. > > The problem, then, is that the selecting request-headers aren't shared > between the client and the server. Also, HTTP caching evaluates > equivalence of selecting request-headers lexically, not based upon > their underlying values. Well request headers involved in the transaction may become part of the package, as well as the reply headers. Meaning that implementation of that feature have to act as compliant caches. > OTOH, an implementation could easily examine the Content-* headers in > order to decide whether it can understand and use a particular > representation. Well it depends if we think of the carried representation as a convenient way to send data without caring much about integrity or we we consider it as a first class URI resolver that should then follow the HTTP rules for caches. You can have the case where many representation are understood but a lower quality one is carried with the SOAP message, like sending a picture as a low quality gif for small devices while a SVG version can be fectched on the network by network-connected projectors. > That said, I think may we need to specify something (perhaps a Header) > that instructs the implementation what to do with URIs WRT falling > back to fetching representations from the network, or not. With conneg we still have the issue of not knowing the available representations, which is a pain. However it would be good to not only have a metadata about the uri cached but also the context, fallback in case of unknown format being only the worst case of what can happen. -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Tuesday, 18 November 2003 21:14:03 UTC