Incomplete URL sent to Akismet API

[Jeroen Vermeulen <jtv@…>]

Akismet integration wasn't working for me (I hope I've fixed it now), in combination with lighttpd and fastcgi: the log just says "invalid API key."

I'm using Trac 0.11 but I see what I think is the problem in the 0.12 version of plugins/0.12/spam-filter-captcha/tracspamfilter/filters/akismet.py​: when calling the Akismet Rest API, the spam filter plugin passes req.base_url for the "blog" parameter. This does the wrong thing when TRAC_BASE_URL is not a full URL to the Trac instance, with protocol and hostname. (In my case it was set to "/development").

In retrospect, this is probably just my mistake in configuring lighttpd but given how sparse its documentation is, I probably won't be the last user to get that wrong. And Akismet's API gives no details beyond "invalid," so debugging this is little fun. (In my case it was about two days, a support session, thirty spam bugs, and a tcpdump trace of fun. ☺)

Assuming there's no good way to make up a host name to send to Akismet if base_url contains none, it'd be helpful if the plugin could detect this particular problem and log it.

Or if it turns out to be almost possible to construct a full URL: Akismet support tells me they normalize protocol and hostname, so subtleties such as https vs. http or a "www." prefix don't matter.

(By the way, love the interactive ticket preview at the bottom of the newticket page! Hadn't seen that before.)

[jtv@…]

Yup, making TRAC_BASE_URL a full URL fixed the problem. Hypothesis confirmed.

[Christian Boos]

Funny, a few minutes ago while working on r10781, I wondered if req.base_url could sometimes not be an absolute URL, and came to the same conclusion (source:tags/trac-0.12.2/trac/web/api.py#L206​).

I don't think allowing relative URLs has any use, so I think we should _reconstruct_url() not only if the 'trac.base_url' is empty, but also if it's not absolute (and that should be flagged as a configuration error).

(Re-targeting for Trac core; of course a specific workaround could be done at the level of the SpamFilter in the meantime)

[jtv@…]

I can't say I really understand what TRAC_BASE_URL is for. Otherwise I wouldn't have come here, I guess.

Might a relative URL not be useful if the site is made available under multiple hostnames, e.g. because the owners found that a more convenient way to migrate from or to a specialized subdomain without breaking links than http redirects?

Also, is there no risk of a full URL forcing http on links, when Trac is rendered through https (or who knows, spdy)?

If neither of these is a problem, then consider the converse question: is there any reason to require a full URL if the hostname only seems to be needed in this one place and the protocol can be safely ignored?