[OpenID] [xrds-simple] Any use of <meta http-equiv="X-XRDS-Location" ...?
John
jpanzer at acm.org
Wed Jul 2 01:32:37 UTC 2008
Yes: Friend Connect is one example.
-John
On Jun 30, 2008, at 8:54 PM, "Manger, James H" <James.H.Manger at team.telstra.com
> wrote:
> OpenIDers,
>
>
>
> Does anyone in the OpenID community know of services that definitely
> need to use <meta http-equiv="X-XRDS-Location"…/>? For instance, ser
> vices that cannot read or set HTTP headers, but still need to suppor
> t 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 i
> f 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 wi
> ll not need an HTML parser for any other task – they will be designe
> d for more precise syntaxes (XML, XHTML, JSON, Atom, key=value…). Th
> ey are likely to look for a <meta http-equiv=…> element in various a
> d 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 gi
> ven 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 step
> s” as it might be 1 step (XRDS returned directly), or it might be mo
> re 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 simplific
> ations) 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 Synta
> x,” .) section 3, it MUST be removed prior to making the request. Th
> e 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
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "XRDS-Simple" group.
> To post to this group, send email to xrds-simple at googlegroups.com
> To unsubscribe from this group, send email to xrds-simple-unsubscribe at googlegroups.com
> For more options, visit this group at http://groups.google.com/group/xrds-simple?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
> uot; group.
> To post to this group, send email to xrds-simple at googlegroups.com
> To unsubscribe from this group, send email to xrds-simple-unsubscribe at googlegroups.com
> For more options, visit this group at http://groups.google.com/group/xrds-simple?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080701/f1d120d4/attachment-0002.htm>
More information about the general
mailing list