W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2003

Re: Strawman proposal for Representation header

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Tue, 18 Nov 2003 14:52:57 -0800
Message-Id: <F3B904B7-1A19-11D8-B046-00039396E15A@bea.com>
Cc: Martin Gudgin <mgudgin@microsoft.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
To: Yves Lafon <ylafon@w3.org>

> Well, UC2 requires more or less to go MIME->XML as well, and all the 
> fun
> 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...

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

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:

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

OTOH, an implementation could easily examine the Content-* headers in 
order to decide whether it can understand and use a particular 
representation.

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.

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems
Received on Tuesday, 18 November 2003 17:53:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT