- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Mon, 28 Mar 2005 20:22:25 -0600
- To: www-svg@w3.org
Ian Hickson wrote: >>At what point is one considered to have hit something "in error" for >>sXBL? > > When the spec says so. Search for "in error" for all the cases that > trigger that condition. I meant chronologically... Hopefully my comments on section 2 make this a little clearer; see them, please? > Section 4.1, which refers to RFC2396, which is obsoleted by RFC3986, whose > section 5.1.3 explicitly states that it is the post-redirect URI that must > be used as the base URI. Ah, ok. Thank you. > I really don't understand. If the URI in question is one which the UA > already has loaded What do you mean by "already has loaded"? Per the specification we're discussing, the only URI comparisons that should be happening are those of post-redirect URIs to URIs in the cache that we have. Given any "starting" URI, an implentation has to perform the following steps, as I see it: 1) Determine what "resolved" URI this "starting" URI will resolve to after all redirects. 2) Look for this "resolved" URI in its "loaded XBL stuff" cache (probably need to include "loading XBL stuff" as well, which is a separate issue). 3) If step 2 doesn't find anything, fetch the data for the URI, parse it, etc. The problem I'm having is with step 1. If there is no data, or only expired data in the HTTP cache for the "starting" URI, then the implemetation has to do an HTTP GET on the "starting" URI to determing the "resolved" URI for step 2. Per the text of the specification, this should happen even if the "starting" URI is already in the cache we access in step 2, since it could now result in a redirect. -Boris
Received on Tuesday, 29 March 2005 02:22:27 UTC