How do we know whether a service URI is available (relatedquestion)

[Johannes Ernst]

On Aug 25, 2006, at 10:34, Drummond Reed wrote:

> Mike,
>
> I personally believe a 404 is the right response because even  
> though the URL
> is correct, the resource is "not found".
>
> So I would keep it as simple as: send an HTTP HEAD request to the  
> SEP URI.
> If the response is 200 OK, it is active. Anything else = inactive.

I would also allow redirect codes. Use case: I create my hand-crafted  
XRDS file that includes services from all over the place, and one of  
the vendors I do business with decides that they move their service  
endpoint because they bought a big shiny new server or something.

>
> =Drummond
>
> -----Original Message-----
> From: Michael Mell [mailto:mike at nthwave.net]
> Sent: Friday, August 25, 2006 9:37 AM
> To: Drummond Reed
> Cc: 'Johannes Ernst'; 'OpenID Discussion'; iss-comment at lists.xdi.org
> Subject: Re: How do we know whether a service URI is available
> (relatedquestion)
>
>
> On Aug 24, 2006, at 10:16 PM, Drummond Reed wrote:
>
>> +1. In fact the HTTP HEAD request may be the lightest-weight  
>> mechanism
>> proposed yet.
>>
>> Mike Mell: would this not be even easier than appending the (+active)
>> query
>> parameter? And avoid the issues about requiring append="qxri"?
>
> Using HEAD is appealing given the append issues we uncovered. The spec
> for HEAD [1] exactly addresses Johannes' case -- the need to determine
> if an end point is operational. To address the +contact case -- the
> need to determine the status of provisioning for a particular persona
> -- would the SP respond with a 404 if the service was not active? A  
> 404 
> is not quite the correct response in this case since the location is
> correct (according to the SEP).
>
> If we don't reply with a 404, the SP response would need to diverge
> from the spec by adding another field in the headers to indicate the
> +active state. The spec says the meta information returned from a HEAD
> SHOULD be identical to the response headers of a GET.
>
> Using a new header field, the querying party would send a HEAD request
> to the unaltered end point url. The SP would add +active=TRUE in the
> response headers. The querying party would examine the headers for an
> +active field and verify the value == TRUE. This is a clean and
> efficient way to achieve the goal. It seems like a good option  
> until we
> have more robust xdi queries available.
>
> +1 for HTTP HEAD with an +active field
>
> Mike
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>
>> =Drummond
>>
>> -----Original Message-----
>> From: yadis-bounces at lists.danga.com
>> [mailto:yadis-bounces at lists.danga.com]
>> On Behalf Of Johannes Ernst
>> Sent: Thursday, August 24, 2006 9:14 PM
>> To: OpenID Discussion
>> Cc: iss-comment at lists.xdi.org; i-broker-discuss at lists.xdi.org
>> Subject: Re: How do we know whether a service URI is available
>> (relatedquestion)
>>
>> Can I ask for a virtual show of hands (-1/0/+1) of people who think
>> that we should have some kind of very lightweight "ping" for OpenID
>> service endpoints in time for the OpenID 2.0 spec, preferably using
>> an approach that works for other kinds of services, too, or not?
>>
>> I was actually thinking of an HTTP HEAD on the service endpoint,
>> looking for an HTTP error code (or TCP timeout) or an HTTP success
>> code. (or a redirect code, in which case the new service endpoint
>> should be pinged instead).
>>
>> But regardless of how we'd specify that ping ... should we have such
>> a thing? Or not? Or "not now"?
>>
>> Cheers,
>>
>>
>>
>> Johannes.
>>
>>
>>
>>
>> Johannes Ernst
>> NetMesh Inc.
>>
>>
>>
>

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060825/1ffef799/lid-0001.gif
-------------- next part --------------
  http://netmesh.info/jernst