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

Tue Jul 1 03:54:30 UTC 2008

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 spec http://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 is http://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.

 1.  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.
 2.  I would omit the stuff about fragments as that is standard HTTP.
 3.  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.
 4.  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.
 5.  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<outbind://3-0000000023A15065FFC1D211BC7500104B08DBF104A93200/eran@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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080701/30594ad5/attachment-0002.htm>