Re: [blogite] Pingback misc

Date view Thread view Subject view Author view Attachment view

From: Jim Dabell (
Date: Sat Sep 07 2002 - 18:03:48 BST

Hash: SHA1

On Friday 06 September 2002 6:17 pm, Stuart Langridge wrote:
> Jim Dabell spoo'd forth:
> > Hi, hope this is a public mailing list, and it's okay to post and not
> > just lurk - I came across this list by accident, so I'm not sure :)
> No worries, get stuck in ;)

Ta :)

> A lot of blogs *are* static, though, because they build static pages
> for rendering speed, even if you do have CGI access to the headers. If
> I were using static pages I certainly wouldn't want to do the overhead
> of kaing all my pages a CGI.

Use .htaccess or the fallback then :)

Also: how many static blogs are likely to be running a pingback server?

> > - - head is not well supported
> >
> > This is the first I've heard about this. What servers don't support
> > head?
> I must confess that I'm taking someone else's word for this. However,
> the someone is Jamie Zawinski, who I expect to know about this stuff.
> From "...then does a GET on
> each of them (not a HEAD, because that doesn't work with all sites)..."

Fallback when you recieve "501 Not implemented" then, and drop the
connection even earlier if you get a pingback http header from your GET :)

> > - - 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.
> I don't agree here. Checking for a reference prevents pingbacks being
> spammed or flooded. I've seen too many examples of protocols where
> people think of this sort of thing later on and find that it's a real
> pain to retrofit; if we make it part of the spec up front then we'll
> never have to worry about it.

Perhaps a recommendation, rather than actually part of the spec? For
instance, in HTML, there is no defined error handling, but there is a
"recommended" approach that virtually all implementations implement.

> > Which (in a roundabout way) leads me to my next question:
> >
> > What are the semantics for changing pages? Suppose you get a pingback,
> > and the referring page deletes the reference to you? Or the site goes
> > offline, never to come back?
> Ah, but Cool URIs Don't Change, remember?

Ah, but this is the _real_ world, remember? ;)

> I'm not necessarily seeing a need to cope with this; after all, links
> that have been blogged may go dead or move and no-one worries about
> that particularly, I don't think?

Good point..

> 1. You should be able to tell a page's pingback URL from the page in
> isolation, because it relates to the page. HTTP headers aren't the page
> at all, they're merely the method by which the page is served, which
> should be irrelevant to what you do with its content. It would be
> possible to serve a site from an ftp server (if you were a nutter) and
> you might still request pingbacks, but there would be no headers -- how
> a page is given to the user is irrelevant. It's the content that's
> important.

Fallback :)

Seriously, though, I see pingback servers as being a property of the blog as
a whole, rather than any specific page. I guess you don't, which is why we
disagree on this point.

> 2. Headers are invisible and weird techie things. It'll be jolly
> difficult to explain them to people (although, I admit, my plan for
> pingback is that it happens automatically without user intervention).

Good point, however if they are using a pre-packaged dynamic blog, then this
can be handled automatically too.

> 3. The LINK tag is, in my opinion, the Right Way to show stuff related
> to a page, like alternative representations or CSS that relates to it.
> That's what it's designed for, and that's how it should be used, I
> think; it's clearly the way to show the pingback server related to a
> page.

I think there's a case to be made for both approaches. Certainly, HTTP
headers are the _definitive_ way to provide meta information about objects
retrieved via HTTP. Content-type, caching, content-language - all are
present in both <head> and http, there is *some* overlap.

The test I would see as being whether or not it should be in the document or
the headers is: does pingback make sense outside of html? If a new
document type took the world by storm, would it still make sense to have
pingback operating on those documents?

I hope I've made it clear that I'm not actively opposing <link>, just
advocating a HTTP header as the authorative information. As noted above,
there is some overlap between HTTP headers and <head> elements, this is
probably one of those cases where both methods should be implemented.

Also, what about xhtml (the proper stuff, not text/html)? Are we going to
have <?xml-pingback ... ?> as well?

- --
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 : Mon Sep 09 2002 - 04:05:01 BST