Re: Strawman proposal for Representation header

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

> >    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
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