The reliance on Content-type

David Recordon david at
Thu Nov 10 00:25:03 PST 2005

I think that sounds reasonable and doesn't complicate things that much.
Would it also make sense to say for the result of the first fetch if you
can't parse it as an HTML document, at the choice of the consumer if
they wish to expend the energy, try parsing it as an XML document? 


-----Original Message-----
From: yadis-bounces at
[mailto:yadis-bounces at] On Behalf Of Martin Atkins
Sent: Thursday, November 10, 2005 12:16 AM
To: yadis at
Subject: The reliance on Content-type

The current spec relies on the returned Content-type value to determine
what kind of document has been retrieved. This is how HTTP was intended,
but in the real world most website owners don't know how to or can't
configure a specific content type for a resource on their site.

In these cases, the XRID file will probably get served as either
text/plain or text/xml. Per the current spec, that would cause the
consumer to flag an error.

I propose, for the sake of "Let's be realistic, here!", that we make a
special allowance for this problem, but *only* in the HTML indirection

Per the current spec, the HTML indirection case involves a LINK element
like the following:
<link rel="identity.capabilities"

The type is spelled out in the LINK element here. My proposal is that in
the case where the type given here is correct, consumers be instructed
to disregard the type returned by the server and attempt XML parsing. If
the root element's namespace is wrong or the document is not well formed
at all failure will soon follow. Consumers should still pay attention to
other aspects of the response, including making sure that the status
code is 200 OK. That way they can fail early if it's a 404 Not Found.

The direct access case is assumed to be used only by people who "know
what they're doing", so we can keep that case simple.

This does make things a little more complicated, but I think it's
important for early adoption.

More information about the yadis mailing list