Crawling sub-domains which share the same server about fetchbot HOT 3 CLOSED

Hello James,

I understand the issue, but this is working as intended, as the robots.txt spec explicitly mentions that:

The directives listed in the robots.txt file apply only to the host, protocol and port number where the file is hosted.
Ex: http://example.com/robots.txt
Valid for: http://example.com/, http://example.com/folder/file
Not valid for: http://other.example.com/, https://example.com/

In fact, if anything the scheme should be added to the key of f.hosts to better comply with the spec.

So they effectively are distinct hosts and should be treated as such, each with their own independent crawl delays. In your case, I'd suggest controlling the queuing by storing the links in a DB and feeding them at a controlled rate into fetcher (maybe with a semaphore using a channel)? Unless you call Cancel on the queue, (in which case you explicitly opt out of processing any pending queued URL) all queued URLs are guaranteed to generate a call to the Handler, so you can acquire a semaphore slot on Send and release it in the Handler.

Hope this helps,
Martin

from fetchbot.

Ahh, okay. Makes sense. I wasn't looking at the CrawlDelay from a robots.txt perspective. I suppose I'm looking for an IP-centric crawling delay rather than one based on host/robots.txt. I'll seek an alternative solution, thanks for the info + quick response!

from fetchbot.

You could use net.LookupIP function to resolve the host first, and enqueue urls using http[s]:///path, but presumably they use virtual hosts based on the subdomain, so that's unlikely to solve your problem.

from fetchbot.