The HTML specification contains a number of algorithms which are
quadratic in complexity by design. Instead of adding complicated
workarounds to prevent these cases from becoming extremely expensive in
pathological cases, we impose a limit of 512 to the size of the stack of
open elements. It is extremely unlikely that non-adversarial HTML
documents will ever hit this limit (but if we see cases of this, we may
want to make the limit configurable via a ParseOption).
Thanks to Guido Vranken and Jakub Ciolek for both independently
reporting this issue.
Fixes CVE-2025-47911
Fixesgolang/go#75682
Change-Id: I890517b189af4ffbf427d25d3fde7ad7ec3509ad
Reviewed-on: https://go-review.googlesource.com/c/net/+/709876
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change ensures that the <search> tag correctly closes an open <p> tag when encountered during parsing.
Changes:
- Added <search> to the list of elements that should close an open <p> tag in parse.go.
- Updated the second list in parse.go to ensure consistency.
- Updated html/atom/gen.go, table.go, and table_test.go accordingly.
- Modified parse_test.go to use strings.Builder instead of bytes.Buffer.
- Updated test error messages to follow Go’s conventions.
- Fixed an accidental colon in the comment in parse.go.
Change-Id: I5835da69f6bb0e14c483e55b7ae82915ae958dc1
Reviewed-on: https://go-review.googlesource.com/c/net/+/655457
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Instead of using strings.ToLower and == to check case insensitive
equality, just use strings.EqualFold, even when the strings are only
ASCII. This prevents us unnecessarily lowering extremely long strings,
which can be a somewhat expensive operation, even if we're only
attempting to compare equality with five characters.
Thanks to Guido Vranken for reporting this issue.
Fixesgolang/go#70906
Fixes CVE-2024-45338
Change-Id: I323b919f912d60dab6a87cadfdcac3e6b54cd128
Reviewed-on: https://go-review.googlesource.com/c/net/+/637536
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Assuming "in head noscript" insertion mode, the scripting flag will be disabled.
Thus, even if nested noscript tags exist,
the tokenizer should not go into the raw text mode.
This change makes the following test happy:
<head><noscript><noscript class="foo"><!--foo--></noscript>
Change-Id: I2620e751d8be3d313c3a2e2f992b1e21ce2dc2ee
Reviewed-on: https://go-review.googlesource.com/c/net/+/263878
Trust: Kunpei Sakai <namusyaka@gmail.com>
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This commit newly introduces a type for configuring a parser
called ParseOption, and implements two functions depending on it.
Along with that, this introduces ParseOptionEnableScripting to
enable setting of the scripting flag.
Fixesgolang/go#16318
Change-Id: Ie7fd7d8ce286e22e7f57182fc2ce353bce578db6
Reviewed-on: https://go-review.googlesource.com/c/net/+/174157
Reviewed-by: Nigel Tao <nigeltao@golang.org>
In the spec 12.2.6.4.5, the "in head noscript" insertion mode is defined.
However, this package and its parser doesn't have the insertion mode,
because the scripting=false case is not considered currently.
This commit adds a test and a support for the "in head noscript"
insertion mode. This change has no effect on the actual behavior.
Updates golang/go#16318
Change-Id: I9314c3342bea27fa2acf2fa7d980a127ee0fbf91
Reviewed-on: https://go-review.googlesource.com/c/net/+/172557
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The existing implementation behaves differently to all major browsers, for the instance where a self-closing element of an unknown tag type is the child of another element of an unknown tag type. The issue appears to be that nested tags of an differing unknown types will all have an atom value of 0 and `inBodyEndTagOther` will incorrectly match them to one another.
Fixesgolang/go#30961
Change-Id: I62b0aa49c027c8432df7d077ffba135201b3b786
GitHub-Last-Rev: fb25181f9a
GitHub-Pull-Request: golang/net#37
Reviewed-on: https://go-review.googlesource.com/c/net/+/168638
Reviewed-by: Nigel Tao <nigeltao@golang.org>
If there are nested <template> elements and the <template> node isn't in HTML namespace,
couldn't continue to parse documents correctly.
By this patch, it makes the <template> which is in math namespace be skipped on
resetting insertion mode.
Fixesgolang/go#27702
Change-Id: I6eacdb98fe29eb3c61781afca5bc4d83e72ba4ed
Reviewed-on: https://go-review.googlesource.com/136875
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The <isindex> element has been removed from the spec so that the
<template> element doesn't cover it.
To avoid panic, this commit adds ignoring code as a workaround.
Fixesgolang/go#27704
Change-Id: I847391389285df2fc0eb6a795f8c93b481cdebac
Reviewed-on: https://go-review.googlesource.com/136575
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The current documentation as well as set of atoms and attributes has
gotten slightly out of sync with the current state of the WHATWG
html5 specification. The change adds and removes several of the atoms
and attributes, updates the documentation (such as steps numbering in
inBodyEndTagFormatting) and modifies the spec URLs to https://
Change-Id: I6dfa52785858c1521301b20b1e585e19a08b1e98
Reviewed-on: https://go-review.googlesource.com/6173
Reviewed-by: Nigel Tao <nigeltao@golang.org>
