Re: proposal for issue 457

On Sun, 22 Feb 2004, Mark Nottingham wrote:

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

character-for-character?

From RFC2616:
<<<<<
   The selecting request-headers from two requests are defined to match
   if and only if the selecting request-headers in the first request can
   be transformed to the selecting request-headers in the second request



Fielding, et al.            Standards Track                    [Page 95]

RFC 2616                        HTTP/1.1                       June 1999


   by adding or removing linear white space (LWS) at places where this
   is allowed by the corresponding BNF, and/or combining multiple
   message-header fields with the same field name following the rules
   about message headers in section 4.2.
>>>>

So it can be safely transformed in a "canonical" form and compared, it's
up to the implementation. A character-to-character comparison may be used
as an optimisation as if it fails it will genereate a new request and will
not violate the "MUST NOT" in the spec, but it's just an optimization.

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

To avoid that issue, the context have the system date of the request and
the reply as seen as the originator. I outlined the potential issue of
clock difference between SOAP sender and receiver, but at least the dates
will be in the metadata given, so that the Age header can be recomputed.
(provided the clocks of the SOAP sender and receiver are in sync, but
that's an issue for almost everything, and I hope that the use of time
servers will reduce that (do someone have stats on that?)


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

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Monday, 23 February 2004 05:32:46 UTC