NWnwellnhof·Mar 31, 2023Submission
Gumbo HTML5 parsing library has been discontinued
1 points · Open discussiongoogle
gumbo-parser
HTML2013–2023
google / gumbo-parser · Archived
gumbo-parser
An HTML5 parsing library in pure C99
16Distinct people
26Mentions
0Explicit recommenders
5.2KGitHub stars
What to know before exploring
What it is
An HTML5 parsing library in pure C99
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year26 dated mentions
Observed mentions: 2013-08-14 02:54:55 UTC to 2023-03-31 15:59:30 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 8 | 3 | 5 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
26 sourcesIt uses libcurl and gumbo (https://github.com/google/gumbo-parser). Gumbo is apparently written in pure C99 (interestingly Curl is written in the even older C89 standard). Will've been more amusing if article was written considering that and used C99.
In Web Scraping with C++oops... I saw a markup parser and automatically thought XML, but you are right! HTML is actually a whole different beast!
As it turns out, seems like nim also has an html parser [1], but I'm guessing something like Google's gumbo [2] could be more reliable, but you would have to write bindings for nim.
1: https://nim-lang.org/docs/htmlparser.html
2: https://github.com/google/gumbo-parser
In Markup Language Operations in Nim to extract and remove HTML elementsThink of error cases and malicious input instead of well-written APIs.
When I was testing Gumbo [1] on all the HTML files in Google's index, I ran into one that had 48,000 levels of nested HTML tags. (Ironically, Gumbo itself handled this fine, but the test script I used to verify the output died.) I posted it to Memegen with a link to the original source URL, and then got called out for crashing Chrome. Apparently I wasn't the only one who didn't think about recursion limits in a parser. (Both bugs have since been fixed.)
What was the wayward HTML file? It was an XML file served with the wrong content type. The file contained 48,000 self-closing tags. When you parse an unknown element with a self-closing tag in HTML, it ignores the trailing />, treats it as an ordinary unknown element, and happily keeps generating a deeper and dee
Read the rest
per DOM.
A stack overflow that results in a segfault is a pretty serious DOS vulnerability in a JSON parser. You probably could take down a good portion of the Internet by sending JSON requests to their AJAX endpoints that consist of 1M of {.
[1] https://github.com/google/gumbo-parser
Ah very cool, had seen various python libraries about HTML5, but not gumbo (or at least I had starred it).
https://github.com/google/gumbo-parser
Is the modified version you use a personal version or a well-known fork?
In Ask HN: What are best tools for web scraping?"He developed the well respected Reva Forth, used by hobbyists around the world. "
Reva Forth always seemed nice but I could never get it working on anything other than Windows.
As such, I have little faith that "8th" will place any value on portability either, e.g., that it will be ported to BSD, Plan 9 or other RPi-compatible OS.
Meanwhile, there are plenty of more portable, open source Forths to choose from.
Example:
ftp -4o cforthu.zip https://codeload.github.com/pahihu/cforthu/zip/master
Some HN commenters are questioning the peculiar security claims.
The author discloses that 8th depends on a number of third party libraries. Would this mean that each of those third parties would also have to make similar security claims to 8th?
For example, 8th uses an HTML5 parsing library from Google called gumbo-parser.
"Non-goals:
Security.
Read the rest
Gumbo was initially designed for a product that worked with trusted input files only. We're working to harden this and make sure that it behaves as expected even on malicious input, but for now, Gumbo should only be run on trusted input or within a sandbox. Gumbo underwent a number of security fixes and passed Google's security review as of version 0.9.1."
source: https://github.com/google/gumbo-parser
It may be the case the only input parsed by 8th is trusted or "within a sandbox" but without the source code how would this be verified?
I made a pull request[1] for gumbo-parser a while ago. While it is a wonderful project, it seems to be in need of a new maintainer, or a maintained fork.
[1] https://github.com/google/gumbo-parser/pull/370
In Show HN: Fast C-based HTML 5 parsing for PythonThe best library I've found for this sort of thing is gumbo. https://github.com/google/gumbo-parser
With its help I've created scrapers and crawlers that digest even the most disgusting HTML.
In HTML parsing in Elixir with leex and yeccThe main reason is so you can statically analyze the template source code. For example, pair Gumbo [1] with an HTML-based templating language and you can identify every image referenced in the HTML and automatically coalesce them into a sprite sheet. You can replace dynamically-generated images with data: URLs and load the data at the end of the page, minimizing latency. You can validate your templates to make sure they never generate invalid HTML. You can run any inline scripts found through Closure Compiler or Babel to minify them (or, in Babel's case, support ES6 directly in templates). You can do CSS renaming automatically on all elements.
A secondary reason is to constrain your users so they don't end up writing constructs that will be impossible to manipulate with tooling. Early in Bazel's [2] history at Google, BUILD files we
Read the rest
re just ordinary Python, and you could use any Python code you wanted, and all that mattered were the calls you made into the build rules. This worked great, with people writing all sorts of list comprehensions and conditionals to minimize code duplication. And then tools came out to reformat BUILD files, and automatically query for dependencies, and detect dead binaries, and all sorts of other cool stuff. The tools were a lot more useful than the ability to include arbitrary code, but (because of the halting problem) they would choke whenever they encountered arbitrary flow constructs. So now arbitrary code is limited to the portions of the build system that explicitly allow it.
The EDSL approach (where you just use a regular programming language and a bunch of calls into the engine) can be a good idea, but you give up a lot in tooling. Usually it's most useful in the early stages of a project, where you don't have manpower to write the tooling anyway, and then becomes a legacy hassle as you assign more engineers, write more code, and get more leverage from writing tools.
[1] https://github.com/google/gumbo-parser
[2] http://bazel.io/
Yeah, one of the compilers I wrote just used JSON as the AST, with it being generated by a GUI interface. Another used HTML with annotations (although go figure, I wrote an HTML parser [1] for it, because there weren't any C++ options at the time that didn't bring along a browser engine). A third had a custom front-end but then emitted Java source code as the back-end.
The interesting thing is that the more experience you get, the more alternatives you find to writing your own language. Could you use Ruby or Python as the front-end, much like Rails [2], Rake [3], or Bazel [4]? Could you build up a data-structure to express the computation, and then walk that data-structure with the Interpreter pattern? [5] Could you get away with a class library or framework, much like how Sawzall has been replaced by Flume [6] and Go libraries within
Read the rest
Google?
In general, you want to use the tool with the least power that actually accomplishes your goals, because every increase in power is usually accompanied by an increase in complexity. There are a bunch of solutions with less power than a full programming language that can still get you most of the way there.
[1] https://github.com/google/gumbo-parser
[2] http://rubyonrails.org/
[3] http://rake.rubyforge.org/
[4] http://bazel.io/
[5] https://en.wikipedia.org/?title=Interpreter_pattern
[6] http://pages.cs.wisc.edu/~akella/CS838/F12/838-CloudPapers/F...
Gumbo HTML parser:
https://github.com/google/gumbo-parser
It's one of the most conformant (if not the most conformant - 0.10.0 passes all html5lib-trunk tests) standalone HTML parsing libraries out there. It has third-party bindings in nearly a dozen different languages. The API is simple, the code is robust and well-tested, and being written in C, it's often a fair bit faster than alternatives.
In Ask HN: Brag about open-source projects you're proud ofAccording to that page, Rakudo is a still a preview release in development. The Python 3.0-3.4 series have been full production releases.
Now, I know that open-source projects are sometimes quite conservative with versioning, and one project's 0.9 may be more stable than another's 2.0. (I maintain an HTML parser [1] that's still on 0.9.3 and yet is more robust and better tested than one that is on 3.8.2.) Is this actually the case with Rakudo, though? You can write real production software with Python 3.4; can you with Rakudo #86?
[1] https://github.com/google/gumbo-parser
In PEP 492 – Coroutines with async and await syntaxIt's because at some point, your code will encounter low-tech technology that doesn't let you set the tabstop. This might be a terminal app, or an actual dumb terminal, or a cut & paste into a textbox on a webpage, or a third-party tool that expects spaces only, or a refactoring tool that you wrote yourself but don't have time to get working with tabs, or a parser that can count characters but has no logic for tabs. When this happens, your tab-based formatting will get messed up, while your spaces-based formatting will look exactly the way you wrote it.
A lot of mysteries about why people don't use clearly-superior technological solutions are solved by understanding that ubiquity is a feature, in many cases the most important feature. I don't use vim because it's the best text editor; I use it because I can be reasonably sure every sin
Read the rest
gle UNIX-like system I ever log into will have it, and once it's in my fingers from having to learn it on a remote server, I might as well use it for daily programming. I don't use HTTP because it's an efficient protocol; I use it because every single device, library, and language speaks it. I didn't write Gumbo [1] in C because I like the language; I did it because every modern language can bind to C libraries, and so this lets a maximum number of people use it.
[1] https://github.com/google/gumbo-parser
The "move" started a couple years ago. I open-sourced a Google project about 18 months ago and the recommended hosting solution was GitHub:
https://github.com/google/gumbo-parser
(Ironically, when posted on Hacker News, one of the first comments was that it was ironic that it was posted to GitHub and not Google Code:
https://news.ycombinator.com/item?id=6210282
In Bidding farewell to Google CodeShowing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.