From: Ian Hickson (ian@hixie.ch)
Date: Sun Sep 08 2002 - 11:30:00 BST
On Sun, 8 Sep 2002, Simon Willison wrote:
>>
>> http://www.hixie.ch/specs/pingback/pingback-0.9
>
> Looks good. There are two things I would suggest we add to the spec:
>
> 1. A set of standard fault codes. The ones I can think of off the top of my
> head are:
> 1 - The specified target URI does not exist on this site
> 2 - The specified target URI is not a PingBack enabled resources (i.e
> not a permalink)
> 3 - The specified source URI did not contain the expected link
> I'm sure there are one or two more - it would definitely make sense to
> standardise on these.
Well, from a comment in the current spec:
<!--
If we want to define error codes, we need some for at least the
following conditions:
* Source doesn't include a link to Target
* Target doesn't exist
* Source doesn't exist
* Pingback is already registered
* Access Denied
In addition, we have the "standard" response codes for things like
"wrong number of arguments", etc.
-->
However, here's why I don't want to have to return error codes: in my
blog, the XML-RPC stuff is actually just a separate input/output module,
and my core code (which doesn't even know XML-RPC exists) has no concept
of error codes, let alone XML-RPC-specific error codes.
You can actually pingback my blog through HTTP GET, HTTP POST
multipart/form, and HTTP POST application/x-www-urlencoded, in addition to
the XML-RPC method.
If you use HTTP GET, say, the return result won't be an XML-RPC XML
fragment. It'll be just a string on its own. And if an error occurs, then
I return a "500 Internal Error", again with a string.
I suppose I could introduce the concept of internal error codes, and have
the output modules translate the error codes into more appropriate numbers
for the output (e.g. various 4xx and 5xx error codes for HTTP). But that
really doesn't fit into my model.
On the other hand, if we said that error code 0 was "a generic error code,
and systems MAY use some of the following error codes", that would work I
guess. I imagine some systems (such as my pingback proxy) would never
really be able to tell what the error was anyway, just that there was one.
More importantly, is anyone ever actually going to use these error codes?
There's no point adding stuff to the spec if no-one has any need for it.
Personally I have no need for error codes. If a pingback fails I silently
ignore it (except for logging the entire transaction), so my code never
uses the fault error codes.
> 2. The X-PingBack HTTP header alternative method of auto discovery.
> The advantage this it allows non-HTML resources on the web to be
> PingBack enabled [...].
The disadvantages are extra overhead (everyone has to implement
X-Pingback, otherwise what's the point), and redundancy (if everyone
implements one, why need the other).
Why do we want two different pingback mechanisms?
Do we ever really want to pingback to a non-(X)HTML document? The spec
current says that only (X)HTML documents may be pinged-back.
> What do people think of the XML processing instruction auto-detection
> method (also mentioned in the above email) ?
I think we definitely should not do this. :-) IMHO we should either stick
with <link>, or switch to X-Pingback. I don't see any need for a third
mechanism, since the other two already cover everything the PI can do.
-- Ian Hickson )\._.,--....,'``. fL "meow" /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.' Message sent over the Blogite mailing list. Archives: http://www.aquarionics.com/misc/archives/blogite/ Instructions: http://www.aquarionics.com/misc/blogite/
This archive was generated by hypermail 2.1.5 : Sun Sep 08 2002 - 12:05:00 BST