[OpenID] Any use of <meta http-equiv="X-XRDS-Location" ...?

Tue Jul 1 18:54:32 UTC 2008

The use case is less of a "service provider" but rather a normal  
user.  If I wanted to link to an XRDS-Simple document from http://www.davidrecordon.com/ 
  it is far simpler for me to do so with a bit of HTML (which I can  
copy and paste) than by setting headers.  I think we've clearly seen  
this in terms of how popular OpenID Delegation is.

--David

On Jun 30, 2008, at 8:54 PM, Manger, James H wrote:

> OpenIDers,
>
> Does anyone in the OpenID community know of services that definitely  
> need to use <meta http-equiv="X-XRDS-Location"…/>? For instance,  
> services that cannot read or set HTTP headers, but still need to  
> support XRDS discovery.
>
> XRDS-Simple [xrds-simple.net] is a draft profile of XRDS.
> One possible simplification is not requiring clients to parse an  
> HTML response looking for
>   <meta http-equiv="X-XRDS-Location" content=”…”/>
> Instead, clients would only need to look for an X-XRDS-Location HTTP  
> header or a Content-Type of application/xrds+xml.
> Parsing HTML is not trivial so avoiding it could be worthwhile [§9.2  
> “Parsing HTML documents” takes almost 60 pages of the 500 page draft  
> HTML5 spechttp://www.whatwg.org/specs/web-apps/current-work/#parsing].
>
>
> James Manger
>
> From: xrds-simple at googlegroups.com [mailto:xrds-simple at googlegroups.com 
> ] On Behalf Of Eran Hammer-Lahav
> Sent: Tuesday, 1 July 2008 10:37 AM
> To: xrds-simple at googlegroups.com
>
> I think we need to post this question to the OpenID community as  
> they are the primary users of this feature. I’ll do it later today  
> if you don’t beat me to it (hint – please do).
> From: Manger, James H
> Sent: Tuesday, 1 July 2008 10:11 AM
> To: 'xrds-simple at googlegroups.com'
>
> Are there really going to be SPs that are sophisticated enough to  
> support discovery, but so basic that they cannot set an X-XRDS- 
> Location header or read an Accept header? I think you are setting  
> the bar too low – at the cost of complicating every client (that now  
> needs an HTML parser).
>
> HTML parsing was originally based on SGML, but is now effectively  
> its own language. The best specification of HTML parsing ishttp://www.whatwg.org/specs/web-apps/current-work/#parsing 
> . “§9.2 Parsing HTML documents” takes almost 60 pages of this 500  
> page draft spec. My guess is that many apps using XRDS-Simple will  
> not need an HTML parser for any other task – they will be designed  
> for more precise syntaxes (XML, XHTML, JSON, Atom, key=value…). They  
> are likely to look for a <meta http-equiv=…> element in various ad  
> hoc ways (regular expressions, XHTML parser, HTML library, indexOf() 
> …) that will mostly work but you can never be certain.
>
> James Manger
> From: xrds-simple at googlegroups.com [mailto:xrds-simple at googlegroups.com 
> ] On Behalf Of Eran Hammer-Lahav
> Sent: Tuesday, 1 July 2008 9:34 AM
> To: xrds-simple at googlegroups.com
>
> I think you went too far... :-)
>
> But these are good points. The reason why HTML discovery is  
> supported is to allow SPs without access to headers or accept  
> requests to still be able to offer discovery. The reason why the  
> second Accept is a SHOULD is because it doesn’t need to be a MUST  
> given that it is for a resource that is only an XRDS document (must  
> be).
>
> The fragment text is to make it clear about the difference between  
> the resource fragment and the location fragment. I’ll take a second  
> look to see if I can simplify it.
> From: xrds-simple at googlegroups.com [mailto:xrds-simple at googlegroups.com 
> ] On Behalf Of Manger, James H
> Sent: Tuesday, 1 July 2008 9:26 AM
> To: xrds-simple at googlegroups.com
> Subject: [xrds-simple] Re: HEAD/GET precedence
>
> Hi Eran,
>
> The language can still be simplified.
>
> I would omit the sentence saying “retrieval is performed in two  
> steps” as it might be 1 step (XRDS returned directly), or it might  
> be more than 2 steps if there are redirects.
> I would omit the stuff about fragments as that is standard HTTP.
> I would omit the 1st sentence in 6.2 about checking the location  
> against the endpoint. That would simply be a server error, which the  
> client would notice after the next request anyway.
> Including “Accept: application/xrds+xml” is a MUST in 6.1 (unless  
> the MUST only refers to the GET? Add another MUST to be clear), but  
> only a SHOULD in 6.2. May as well make it MUST in both cases.
> Does anyone really need the <meta http-equiv=”…”/> option? That  
> would be a good one to drop in the XRDS-Simple profile, particularly  
> as parsing HTML is non-trivial (unless making some ad hoc  
> simplifications) and quite different from parsing XML.
>
> My revised suggestion:
>
> 6. Document Retrieval
>
> On receiving a GET request with an Accept header listing application/ 
> xrds+xml, the server SHALL respond with:
> The metadata document, delivered with a Content-Type of application/ 
> xrds+xml; or
> An X-XRDS-Location header whose value is an absolute HTTP(S) URI of  
> the metadata document.
> The server may respond with HTTP redirects at any point.
>
> Any fragment identifier in the URI that delivers the metadata  
> document identifies an XML element with a matching xml:id attribute  
> value.
>
> James Manger
> From: xrds-simple at googlegroups.com [mailto:xrds-simple at googlegroups.com 
> ] On Behalf Of Eran Hammer-Lahav
> Sent: Saturday, 28 June 2008 8:54 AM
> To: xrds-simple at googlegroups.com
> Subject: [xrds-simple] Re: HEAD/GET precedence
>
> Proposed language for draft 2:
>
> ---
> 6.  Document Retrieval
>
> The Consumer obtains the Metadata Document by requesting the  
> application/xrds+xml content type representation of the Resource.  
> XRDS-Simple only defines a retrieval method for HTTP(S) Endpoints.  
> While XRDS-Simple supports descriptions of non-HTTP(S) Endpoints,  
> the method in which their associated Metadata Document is retrieved  
> is beyond the scope of this specification.
>
> Document retrieval is performed in two steps. First the document's  
> location is obtained from the Endpoint, then the location obtained  
> is used to request the Metadata Document.
>
> 6.1.  Obtaining Location
>
> The Consumer MUST issue an HTTP(S) GET request to the Endpoint and  
> include an Accept header specifying content type application/xrds 
> +xml. If the Endpoint contains a fragment as defined by [RFC3986]  
> (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic  
> Syntax,” .) section 3, it MUST be removed prior to making the  
> request. The Service Provider response MUST be one of four options:
> An HTTP redirect response with a Location header which the Consumer  
> MUST follow by repeating the GET request with the provided URI.
> A Content-Type header with value application/xrds+xml. In this case  
> the response body is the Metadata Document and the workflow ends  
> successfully skipping the step described in Section 6.2 (Requesting  
> Document).
> An X-XRDS-Location header where the value of the header MUST be an  
> absolute HTTP(S) URI which gives the document's location.
> A valid HTML document in the response body, with a <head> element  
> that includes a <meta> element with an http-equiv attribute equals  
> to X-XRDS-Location. The value of the <meta> element content  
> attribute MUST be an absolute HTTP(S) URI which gives the document's  
> location.
>
> The Consumer MUST check the Service Provider's response for one of  
> the four options in the order they are listed above, and MUST stop  
> as soon as a match is found. If no match is found, the protocol  
> fails and the discovery workflow ends unsuccessfully.
>
> NOTE: The Consumer MAY attempt to issue an HTTP(S) HEAD request to  
> the Endpoint specifying the content type prior to issuing the  
> HTTP(S) GET request. If the Service Provider's response is a  
> redirect, or includes the X-XRDS-Location header without a Content- 
> Type header with value application/xrds+xml, the Consumer can skip  
> the HTTP(S) GET request, otherwise will have to repeating both  
> requests. Using the HEAD request is NOT RECOMMENDED unless the  
> Consumer knows the Service Provider is likely to reply with a  
> redirect response or an X-XRDS-Location header without a Content- 
> Type header with value application/xrds+xml.
>
> 6.2.  Requesting Document
>
> The Consumer SHOULD check if the document's location is identical to  
> the Endpoint, excluding any differences in the URI fragments. If the  
> URIs are considered identical, the discovery workflow ends  
> unsuccessfully as that request has already failed to produce a valid  
> XRDS-Simple document.
>
> The Consumer MUST request the Metadata Document from the location  
> URI using an HTTP(S) GET request and SHOULD include an Accept header  
> specifying content type application/xrds+xml. The Consumer MUST  
> follow any HTTP redirect responses received while requesting the  
> Metadata Document.
>
> The Service Provider MUST reply with a valid XRDS-Simple document in  
> the response body. The Response SHOULD include the Content-Type  
> header with value application/xrds+xml. If the response is not a  
> valid XRDS-Simple document, the discovery workflow ends  
> unsuccessfully.
>
> If the document's location URI contains a fragment (not to be  
> confused with an Endpoint fragment), it is used as an XRD identifier  
> pointing to a specific XML element with an xml:id attribute of an  
> identical value. The XRD identifier is described in Section 8.1 (XRD  
> Identification).
> ---
>
> I am not even sure we need to keep the HEAD protocol reference. HTTP  
> defines how HEAD should work and this is really just a simple HEAD  
> use cases. This text *does* change the discovery flow from XRI  
> Resolution 2.0 in that it looks for the xrds content type header  
> before the X-XRDS-Location header.
>
> EHL
>
>
> On 6/21/08 10:57 PM, "Eran Hammer-Lahav" <eran at hueniverse.com> wrote:
>
>
> Reviewing my list of open issues for draft 2, I read this post a  
> second time and tend to agree with James analysis in his first point.
>
> Can any of the Yadis/OpenID authors explain why we have this  
> inconsistency between GET and HEAD? If that can be resolved I would  
> like to adopt the second suggestion.
>
> EHL
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080701/6ce25085/attachment-0002.htm>