HTMLParser lukewarm on bogus bare attribute chars

[mkc]

BPO	975556
Nosy	@devdanzin, @bitdancer
Superseder	bpo-1486713: HTMLParser : A auto-tolerant parsing mode

^{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:

assignee = None
closed_at = <Date 2010-12-03.04:14:13.145>
created_at = <Date 2004-06-18.19:33:18.000>
labels = ['type-feature', 'library']
title = 'HTMLParser lukewarm on bogus bare attribute chars'
updated_at = <Date 2010-12-03.04:14:13.143>
user = 'https://bugs.python.org/mkc'

bugs.python.org fields:

activity = <Date 2010-12-03.04:14:13.143>
actor = 'r.david.murray'
assignee = 'none'
closed = True
closed_date = <Date 2010-12-03.04:14:13.145>
closer = 'r.david.murray'
components = ['Library (Lib)']
creation = <Date 2004-06-18.19:33:18.000>
creator = 'mkc'
dependencies = []
files = []
hgrepos = []
issue_num = 975556
keywords = []
message_count = 5.0
messages = ['60515', '60516', '81438', '121676', '123175']
nosy_count = 5.0
nosy_names = ['mkc', 'nnseva', 'ajaksu2', 'Neil Muller', 'r.david.murray']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'resolved'
status = 'closed'
superseder = '1486713'
type = 'enhancement'
url = 'https://bugs.python.org/issue975556'
versions = ['Python 2.7']

[mkc]

I tripped over the same problem mentioned in bug
bpo-921657 (HTMLParser.py), except that my bogus attribute
char is '|' instead of '@'.

May I suggest that HTMLParser either require strict
compliance with the HTML spec, or alternatively that it
accept everything reasonable? The latter approach
would be much more useful, and it would also be
valuable to have this decision documented.

In particular, 'attrfind' needs to be changed to accept
(following the '=\s*') something like the subpattern
given for 'locatestarttagend' (see the "bare value" line).

[nnseva]

Logged In: YES
user_id=325678

see request bpo-1046092 to fix it

[devdanzin]

Per bpo-921657, looks like the current behavior is correct.

[NeilMuller]

This should probably be solved as part of bpo-1486713 .

[bitdancer]

The new strict=False mode from bpo-1486713 handles this case.