Re: Problems with `nnweb' mode

[Tassilo Horn]

Andreas Seltenreich <seltenreich@gmx.de> writes:

Hi Andreas,

> Sorry if I was unclear. The angle brackets have to be *removed* and
> not URL encoded in order for the search to work. The brackets in the
> Message above indicate that they weren't.

Ok, I removed the brackets and the request works. :-)

>>> [snip]
>>
>> Yes, works for me as well.
>
> This is a bit baffling, since the current code should produce exactly
> the same request when referring the id, and mm-url-use-external and
> mm-url-program are bound to the same values. I'd be desperate enough
> by now to use tcpdump to see what is actually going through the ether.

Hey, the tcpdump-thing was a good idea. When executing your snipped
(which worked), the requests go to 64.233.167.99, which is a google
server. If I click a message-id, the tcpdump records only packets with
destination "sea.gmane.org.nntp", so google never seems to be asked.

My config is as follows:

(setq gnus-refer-article-method
      '(current
        (nntp "newshost.uni-koblenz.de")
        (nntp "news.gmane.org")
        (nnweb "gmane"
               (nnweb-type gmane))
        (nnweb "google"
               (nnweb-type google))))

That's the way I'd like it to work: First try to lookup the article in
the local agent cache, if that fails try the nntp-servers of my
university and gmane, and if that fails, too, try to get it from gmane
or google.

But as I said: When I press RET on this example message-id in this
thread, tcpdump records only packets with destination
"sea.gmane.org.nntp". As the current thread is in a gmane group, it
seems to correspond to the "current" refer method, I'd say. The
message-id corresponds to an article on
de.comp.hardware.laufwerke.festplatten, so gmane is the wrong partner
here. 

But why doesn't it try to get it at the other alternatives?

Kind regards,
Tassilo
-- 
98% of us Americans are hard-working people. It's the other 2% that give
us a bad reputation. Then again, we did elect them.