Re: [blogite] Pingback misc

Date view Thread view Subject view Author view Attachment view

From: Jim Dabell (
Date: Sat Sep 07 2002 - 17:38:04 BST

Hash: SHA1

On Friday 06 September 2002 6:45 pm, Simon Willison wrote:
> At 17:48 06/09/2002 +0000, Jim Dabell wrote:
> >There is no reason to not support both - if you can't implement the http
> >header method for some reason, you can include it in a <link> element -
> > if a pingback implementation doesn't find the http header, it can
> > always try the other method.
> My biggest objection to the HTTP header method is this: A very, very
> large proportion of the sites linked to will not have PingBack of any
> kind. This means that for most sites you are linking to you will have to
> perform a HEAD request, see that they don't have a PingBack header, then
> perform a second GET request and see that they don't have a <link>
> element either. That's two requests, which is actually a greater overhead
> than just sending a GET!

Surely the overhead for HEAD in this context is negligable?

> Also remember that you can read data from a socket line by line (or
> character by character if needs be). This means that you can close the
> socket connection from the GET request the moment you receieve a <link
> rel="pingback" element OR you hit the </head> tag (as the link element
> will not appear past that point). This means the overhead isn't actually
> that bad.

Think about all the screwed up html without </head> or <body>, coupled with
thousands of keywords etc. Sure, you can drop the connection after 32k or
whatever, but that's a big difference to a few lines of HTTP headers. You
could also require that the <link> is the first element of <head>, but I
think adding parsing requirements on top of standard html is a mistake.

> >- - pingback checks to make sure the permalink url is actually in the
> > page
> >
> >It seems to me that this should be an optional part of the spec anyway -
> >some implementations won't want the overhead.
> While I agree with Stuart that it is a very, very good idea for a
> PingBack implementation to check for a link on the page I agree with you
> that this should be optional. I think the PingBack specification should
> pretty much boil down to what amounts to a single line of text:
> Blog A tells blog B: "I have linked to your page X from my page Y"


> This doesn't even have to be done via XML-RPC (although that should be
> the favoured method).

The "correct" approach imho would seem to be <link>ing (or HEADing) to a
description of the available pingback interfaces instead of directly to the
service. You could list several:

        <interface priority="1" type="xml-rpc">
        <interface priority="1" type="http-get">
        <interface priority="2" type="email">
        <interface priority="10" type="manual-web-form">
        <interface priority="10" type="manual-email">

> Getting back to the overhead problem, I have a working prototype of a
> centralised system that could severely reduce overhead by helping blogs
> maintain an internal list of which URLs are PingBack-able (and which
> server they should ping).

I *much* prefer autodiscovery. A client could (optionally) keep a cache of
the last few sites linked to, to avoid overhead of checking the same site
ten times a day, but that should _really_ be implementation-specific.

> Oh, and welcome to the list :)

Ta :)

- --
Jim Dabell

Version: GnuPG v1.0.7 (GNU/Linux)


Message sent over the Blogite mailing list.

Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.5 : Sat Sep 07 2002 - 19:05:01 BST