I would propose instead that the doc be changed to refer to the new file, with more and better examples, but add a note that robotparser interprets empty files as 'block all' rather than 'allow all'.
(...) refers users, for file structure, to http://www.robotstxt.org/orig.html. This says nothing about the effect of an empty file, so I don't see this as a bug.
That is incorrect. From that url you can find:
The presence of an empty "/robots.txt" file has no explicit associated semantics, it will be treated as if it was not present, i.e. all robots will consider themselves welcome.
There is a behavior change. parse() sets the modified time and unless the modified time is set the can_fetch method returns false. In Python 2 the parse method was called only when the file is non-empty [0] but in Python 3 it's always called though the file is empty [1] . The change was done with 1afc169 to always read parse and then in 122541b modified function was always called during parse thus setting the modified_time to return True from can_fetch in the end.
I think the behavior of robotparser for empty file was undefined allowing these changes and it will be good to have a test for this behavior.
Thanks @XTreak for providing some clarification on this behavior! I can write some tests to cover this behavior, assuming that we agree that an empty file means "unlimited access". This was worded as such in the old internet draft from 1996 (section 3.2.1 in https://www.robotstxt.org/norobots-rfc.txt). The current draft is more ambiguous with "If no group satisfies either condition, or no groups are present at all, no rules apply." https://tools.ietf.org/html/draft-koster-rep-00#section-2.2.1
https://www.robotstxt.org/robotstxt.html clearly states that an empty file gives full access, but I'm getting lost in figuring out which is the official spec at the moment :-)
Activity
larsfuse commented on Dec 11, 2018
The standard (http://www.robotstxt.org/robotstxt.html) says:
Here I give python an empty file:
$ curl http://10.223.68.186/robots.txt
$
Code:
Result:
And the result is, robotparser thinks the site is blocked.
terryjreedy commented on Dec 14, 2018
https://docs.python.org/2.7/library/robotparser.html#module-robotparser
and
https://docs.python.org/3/library/urllib.robotparser.html#module-urllib.robotparser
refers users, for file structure, to http://www.robotstxt.org/orig.html.
This says nothing about the effect of an empty file, so I don't see this as a bug. Even if it was, I would be dubious about reversing the effect without a deprecation notice first, and definitely not in 2.7.
I would propose instead that the doc be changed to refer to the new file, with more and better examples, but add a note that robotparser interprets empty files as 'block all' rather than 'allow all'.
Try bringing this up on python-ideas.
larsfuse commented on Dec 17, 2018
That is incorrect. From that url you can find:
So this is definitely a bug.
andreburgaud commented on Jan 2, 2020
Hi,
Is this ticket still relevant for Python 3.8?
While running some tests with an empty robotstxt file I realized that it was returning "ALLOWED" for any path (as per the current draft of the Robots Exclusion Protocol: https://tools.ietf.org/html/draft-koster-rep-00#section-2.2.1 ")
Code:
Output:
tirkarthi commented on Jan 2, 2020
There is a behavior change. parse() sets the modified time and unless the modified time is set the can_fetch method returns false. In Python 2 the parse method was called only when the file is non-empty [0] but in Python 3 it's always called though the file is empty [1] . The change was done with 1afc169 to always read parse and then in 122541b modified function was always called during parse thus setting the modified_time to return True from can_fetch in the end.
I think the behavior of robotparser for empty file was undefined allowing these changes and it will be good to have a test for this behavior.
[0]
cpython/Lib/robotparser.py
Lines 66 to 67 in f82e59a
[1]
cpython/Lib/urllib/robotparser.py
Lines 69 to 70 in 149175c
andreburgaud commented on Jan 2, 2020
Thanks @XTreak for providing some clarification on this behavior! I can write some tests to cover this behavior, assuming that we agree that an empty file means "unlimited access". This was worded as such in the old internet draft from 1996 (section 3.2.1 in https://www.robotstxt.org/norobots-rfc.txt). The current draft is more ambiguous with "If no group satisfies either condition, or no groups are present at all, no rules apply." https://tools.ietf.org/html/draft-koster-rep-00#section-2.2.1
https://www.robotstxt.org/robotstxt.html clearly states that an empty file gives full access, but I'm getting lost in figuring out which is the official spec at the moment :-)
3 remaining items
pythongh-79638: Treat an unreachable robots.txt as "disallow all"
pythongh-79638: Treat an unreachable robots.txt as "disallow all"
gh-79638: Treat an unreachable robots.txt as "disallow all" (GH-138555)
Revert "pythongh-79638: Treat an unreachable robots.txt as "disallow …
gh-79638: Test other HTTP error codes besides 403 in test_robotparser (…
serhiy-storchaka commented on May 8, 2026
Since currently robotparser disallows access to all resource if the HTTP status code was 500-599, adding new tests is enough.
[3.13] gh-79638: Test other HTTP error codes besides 403 in test_robo…
[3.14] gh-79638: Test other HTTP error codes besides 403 in test_robo…
[3.15] gh-79638: Test other HTTP error codes besides 403 in test_robo…
gh-79638: Restore "Treat an unreachable robots.txt as disallow all" (G…
[3.13] gh-79638: Restore "Treat an unreachable robots.txt as disallow…
[3.14] gh-79638: Restore "Treat an unreachable robots.txt as disallow…
[3.15] gh-79638: Restore "Treat an unreachable robots.txt as disallow…
pythongh-79638: Restore "Treat an unreachable robots.txt as disallow …