New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make robotparser.RobotFileParser ignore blank lines #57490
Comments
When attempting to parse a robots.txt file which has a blank line between allow/disallow rules, all rules after the blank line are ignored. If a blank line occurs between the user-agent and its rules, all of the rules for that user-agent are ignored. I am not sure if having a blank line between rules is allowed in the spec, but I am seeing this behavior in a number of sites, for instance: http://www.whitehouse.gov/robots.txt has a blank line between the disallow rules all other lines, including the associated user-agent line, resulting in the python RobotFileParser to ignore all rules. http://www.last.fm/robots.txt appears to separate their rules with arbitrary blank lines between them. The python RobotFileParser only sees the first two rule between the user-agent and the next newline. If the parser is changed to simply ignore all blank lines, would it have any adverse affect on parsing robots.txt files? I am including a simple patch which ignores all blank lines and appears to find all rules from these robots.txt files. |
Blank lines are allowed according to the specification at http://www.robotstxt.org/norobots-rfc.txt, section 3.3 Formal Syntax. The issue also seems to exist on 3.2 and 3.3. |
Because of the line break, clicking that link gives "Server error 404". The way I read the grammar, 'records' (which start with an agent line) cannot have blank lines and must be separated by blank lines. Other than than, the suggestion seems reasonable, but it also seems like a feature request. Does test/test_robotparser pass with the patch? I also do not see "Crawl-delay" and "Sitemap" (from whitehouse.gov) in the grammar referenced above. So I wonder if de facto practice has evolved. Philip S.: do you have any opinions? |
I don't see a line break, but the comma after the link seems to breaks it. Sorry.
Ah, true. But it seems to me that having blank lines elsewhere doesn't break the parsing. If other robots.txt parser implementations allow arbitrary blank lines, we could add a strict=False parameter to make the parser non-strict. This would be a new feature of course. Does the parser currently handle blank lines between full records (agentline(s) + ruleline(s)) correctly?
The spec says: Lines with Fields not explicitly specified by this specification So these seem to be nonstandard extensions. |
Sorry, the visual linebreak depends on font size. It *is* the comma that caused the problem. You missed my question about the current test suite. Senthil, you are the listed expert for urllib, which includes robotparser. Any opinions on what to do? |
I agree with your interpretation of the RFC. The parsing rules do not specify any provision for inclusion of blank lines "within" the records. However, I find that inclusion is no harm either. I checked that with a robots.txt parser (Google webmaster tools) and presented the last.fm's robots.txt file which had blank line within records. As expected, it did not crib. I would say that we can be lenient on this front and the question would if we allow, would it break any parsing rules? I think, no. The patch does not break any tests, but a new test should be added to reflect this situation. I don't have a strong opinion on having a strict=(True|False) for the blank line accommodation within records(only). I think, it is better we don't add a new parameter and just be lenient. |
Since following the spec is not a bug, this issue is a feature request for 3.3. I agree with just being lenient with no added parameter. Perhaps that should be mentioned in the doc with (or in) a version-added note. Senthil: does doc standard allow something like Version added 3.3: Ignore blanks lines within record groups. |
If it's added it should be a versionchanged, not a versionadded. |
The robotparser is currently doing exactly what it is documented as doing. 20.9. urllib.robotparser — Parser for robots.txt '''The file consists of one or more records separated by one or more blank lines (terminated by CR,CR/NL, or NL). Each record contains lines of the form "<field>:<optionalspace><value><optionalspace>".''' The formal grammar says the same thing. The page goes on with '''Comments ... are discarded completely, and therefore do not indicate a record boundary.''' followed by '''The record starts with one or more User-agent lines, followed by one or more Disallow lines, as detailed below. Unrecognised headers are ignored.''' Not allowing blank lines within records is obviously, to me, intentional and not an accidental oversight. It aids error detection. Consider: User-agent: A ... User-aget: B ... Currently, the blank line signals a new record, the misspelled 'User-aget' line is ignored, and the new record, starting with 'Disallow' instead of 'User-agent' is correctly seen as an error and ignored. The same would be true if the User-agent line were accidentally omitted. When humans edit files, perhaps from someone else's notes, such things happen. With this change, the second disallow line will be incorrectly attributed to A. We can justify that on the hypothesis that intentional blank lines within record, in violation of the standard, are now more common than missing or misspelled User-Agent lines. Or we can decide that mis-attributing Disallow lines is a lesser sin than ignoring them. But the change is pretty plainly a feature change and not a bug fix. My current suggested doc change is to replace the sentence quoted at the top with Side note: The example in the doc uses musi-cal.com. We need a replacement as it was closed last June, as noted in |
Sounds good to me. |
First, I’d like to remind that the robots spec is not an official Internet spec backed up by an official body. It’s also not as important as (say) HTTP parsing. For this bug, IMO the guiding principle should be Postel’s Law. What harm is there in being more lenient than the spec? People apparently want to parse the robots.txt with blank lines from last.fm and whitehouse.gov, and I don’t think there are people that depend on the fact that blank lines cause the rest of the file to be ignored. Hence, I think too that we should be pragmatic and allow blank lines, to follow the precedent established by other tools and be pragmatic. If you feel strongly about this, I can contact the robotstxt.org people. |
My suggested doc change is how to change the doc along with the patch. |
Does the whole discussion died down? Was there any followup which isn't linked? I've just experienced substantial surprised Pikachu face that our project scraped web pages disallowed in robots.txt just because someone added blank lines inside a record (which is very common). Yes, spec (which we didn't read) is linked in docs but I seriously don't think that most people working in web-related stuff know HOW SUBSTANTIAL single blank line is inside robots.txt record. Simple visual aid makes the rule not do its job. To prove that people have no idea is a fact that https://www.last.fm/robots.txt is still going strong with these visual aids AFTER 12 YEARS. The case with invalid record
doesn't justify how blank lines are treated in spec. Most people will consider the above broken anyway because of the typo and will consider example below as not broken but hard to read:
If you know it you know, but if not, in worst case website owner will start legal action against someones crawler which they can defend with "your file doesn't follow the spec that's why we crawled these pages" hoping that owner will get it the first time and won't have bunch of bored lawyers who wait to get their hands dirty. Moreover I think test cases in EDIT: What is even more stupid (from human perspective not programmers) is that if I put e.g. one space/tab in every blank line then file works as expected. COME ON! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: