Re: proposal for issue 457

Yves,

Because this is specified as a HTTP cache, if the request metadata that 
is used to vary a response doesn't exactly (character-for-character) 
match that generated by the URL resolver, it'll be a cache miss. This 
forces sending implementations to know the implementation details of 
receiving URL resolvers ahead of time, or to not use these mechanisms.

Also, I think we'd need to be very careful to assure that the semantics 
of headers aren't muddied by encapsulation; for example, the Age header 
could be misleading at best if a SOAP intermediary is interposed.

Cheers,


On Feb 13, 2004, at 6:25 AM, Yves Lafon wrote:

>
> Here is a proposal to accomodate the HTTP use case for UC2 to allow an
> implementation to act as a URI resolver using a local cache.
> Note that it is not a proposal to actually describe a complete portable
> cache (ex: it does not address the variant lists)
> The goal here is to give all information used to reconstruct the
> information a cache would need.
> The calculation of the age and cache validity is up to the 
> application, as
> the originator should not be forced to undertand the caching issues of
> HTTP/1.1
> Exemple:
>
> <htx:env xmlns:htx="http://www.w3.org/2004/02/xop/http">
>  <htx:request>
>    <htx:request-line name="GET" version="HTTP/1.1">
>      /someuri/us.png
>    </htx:request-line>
>    <htx:header name="Accept">
>     image/png,image/jpeg,image/gif
>    </htx:header>
>    <htx:header name="Accept-Encoding">
>     gzip,deflate,compress;q=0.9
>    </htx:header>
>    <htx:header name="Date">
>      Fri, 13 Feb 2004 11:23:28 GMT
>    </htx:header>
>    [...]
>  </htx:request>
>  <htx:reply>
>   <htx:status-line version="HTTP/1.1" status="200">
>    OK
>   </htx:status-line>
>   <htx:header name="Content-Type">
>     image/png
>   <htx:header>
>   <htx:header name="Date">
>    Fri, 13 Feb 2004 11:23:28 GMT
>   </htx:header>
>     [...]
>   </htx:reply>
> </htx:env>
>
> It is mainly the complete headers and request/status line for the 
> request
> and the reply, as context of the attached binary.
>
> Also, for completeness, the local time when the request is issued 
> (usually
> there in the Date: header) and the local time of the same machine when 
> the
> reply is received would be a good addition to cope with clock issues,
> something like <htx:time>{RFC 1036 time string}</htx:time> in
> <htx:request> and <htx:reply>
>
> The only remaining issue regarding time (not fixed) is the possible 
> clock
> desynchronization between the SOAP sender and the SOAP recipient.
>
> -- 
> Yves Lafon - W3C
> "Baroula que barouleras, au tiéu toujou t'entourneras."
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems