[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] Alternative to Resolution Errors inside Descriptors
I think passing through the error code, as Dave proposes, probably is fine. That's certainly what happens with today's HTTP proxies. I notice the "via:" header for proxy/gateways is REQUIRED (RFC section 14.45, however, and wonder whether we should abide by this requirement. We are sort of a gateway or a proxy, but its not clear that we fall within the intent of gateway and proxy in RFC 2616. Hmm. -Gabe > -----Original Message----- > From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] > Sent: Thursday, January 27, 2005 4:13 PM > To: Wachob, Gabe; xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] Alternative to Resolution Errors > inside Descriptors > > I'd support this general approach. Thinking about it more, > I'm inclined > to require that the XRID chain be returned in the response > and that the > client pass on whatever error code it received from the upstream > resolver. For example, if the authoritative resolver returns > a 404, the > proxy/lookahead resolver passes that along to the client together with > the chain of successful resolutions. No change there. But if the > authoritative resolver returns a 500 (Internal Server Error), for > example, the proxy/lookahead resolver returns the same code to the > client along with the chain of successful resolutions. The client can > distinguish between an immediate and upstream error by the body of the > message (i.e. whether or not there's an XRID chain included in the > response) and has full information about why the upstream request > failed. > > Dave > > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Thursday, January 27, 2005 4:03 PM > To: xri-editors@lists.oasis-open.org > Subject: [xri-editors] Alternative to Resolution Errors inside > Descriptors > > After some discussion internally, it became clear that there is an > alternative, and much less drastic proposal that would satisfy our > needs. > > Basically, when a proxy (or lookahead) resolver performed a > request that > had resulted (somewhere along the authority chain) in a failed > resolution (either because an authority could not be contacted, or > because an authority said a subsegment was not found, or > other reasons), > the proxy/lookahead would return to the client an HTTP error status > code, and as content within the error code response body, the XRI > Descriptor elements it had *successfully* retrieved until encountering > an error. This complies with RFC 2616 which (for both 4xx and > 5xx status > codes) allows an entity in the response that contains an > explanation of > the error condition. > > Now, we also would like to distinguish between the following > situations: > * the error occurred because the authoritative authority affirmatively > does not know about the subsegment - ie it is not registered > * there is some other error with the authority resolution > process, like > a authority server is down, or a URL is incorrect > > The proposal is that the error condition returned by a proxy/lookahead > is 404 Not Found if the authoritative authority affirmatively says it > can't find the subsegment and 502 Bad Gateway if the authoritative > server was unreachable or otherwise failed. > > I'd propose that returning the successful XRIDescriptor elements is a > SHOULD requirement (but the HTTP error codes would be a MUST). Also, I > *don't* think this has any effect on trusted rez, since the negative > results are, of course, unsigned (and therefore untrustable > as negative > responses). > > Example: > > This result might occur when lookahead resolving > xri://@yoyodyne*labs at > the @ root and @yoyodyne explicitly states *labs is not registered: > > HTTP/1.1 404 Not Found > <other headers> > > <XRIDescriptors ...> > <XRIDescriptor> > <Resolved>@</Resolved> > ... > </XRIDescriptor> > <XRIDescriptor> > <Resolved>*yoyodyne</Resolved> > ... > </XRIDescriptor> > </XRIDescriptors> > > Note that a 502 Bad Gateway HTTP status code might indicate that the > authority server for @yoyodyne could not be contacted or had > a bad HTTP > URL in the descriptor for *yoyodyne.. > > There's some issue about whether or not we are overloading these HTTP > status codesand whether or not, as a practical matter that > non-XRI-resolution error conditions might happen when the XRI > resolution > might otherwise be successful and confuse resolvers. > > In general, however, I think it's a good reuse of HTTP - Mark Baker's > "HTTP is an application protocol, not a Pipe" mantra keeps on > reverberating in my head... > > -Gabe > > > -----Original Message----- > > From: Wachob, Gabe [mailto:gwachob@visa.com] > > Sent: Thursday, January 27, 2005 9:49 AM > > To: xri-editors@lists.oasis-open.org > > Subject: [xri-editors] Resolution Errors inside Descriptors > > > > I have a use case where I would like to know that a > resolution failed > > and have that result expressed inside of an XRI Descriptor. > > > > Take the case where I am using lookahead (or proxied) trusted > > resolution. If I request resolution of a subsegment that is not a > > subsegment the responding authority is directly responsible for, how > > does the proxy/lookahead resolver let me know as a client > > that there is > > such a failure? If I'm resolving directly to an authority, I > > get a 404 - > > but if I'm getting the result *indirectly*, we haven't said > how such a > > negative result is expressed or cached. > > > > So I therefore think we need to have a mechanism for expressing a > > negative result that can be cached and signed. Just an > > element inside a > > XRI Descriptor - something like "Failure" or "Error" which > contains a > > code (a URI) and a textual description (which we don't > specify - as in > > HTTP). Now, there are a lot of concerns about extensibility and the > > ability of a processor to only partially undersatnd an > error condition > > (such as HTTP's use of 3-digit error codes, or SOAP's use of > > hierarchical error codes - from most general to more > specific) - this > > allows expression of as specific an error code as one > wishes, without > > loss of appropriate behavior by processing nodes that don't > understand > > themore specific error, but understand something more general. > > > > I'm not sure what mechanism we should use. I really don't > > want to invent > > a bunch of error codes, or a complicated error extension > mechanism, so > > the simplest thing we could do would be best. Do we need to > go beyond > > something like: > > > > <Failure> > > <Code>..some uri..</Code> > > <Description>...english language description...</Description> > > ... extension elements ... > > </Failure> > > ? > > > > -Gabe > > > > __________________________________________________ > > gwachob@visa.com > > Chief Systems Architect > > Technology Strategies and Standards > > Visa International > > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > > > > > To unsubscribe from this mailing list (and be removed from > > the roster of the OASIS TC), go to > > http://www.oasis-open.org/apps/org/workgroup/xri-editors/membe > rs/leave_workgroup.php. > > > > > > To unsubscribe from this mailing list (and be removed from > the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/xri-editors/membe > rs/leave_w > orkgroup.php. > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.302 / Virus Database: 265.8.1 - Release Date: 1/27/2005 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]