New Bug
New Bug
[Cueball sits at his desk in front of his computer leaning back and turning away from it to speak to a person off-panel.] Cueball: Can you take a look at the bug I just opened? Off-panel voice: Uh oh.
[Zoom out and pan to show only Cueball sitting on his chair facing away from the computer, which is now off-panel. The person speaking to him is still of panel even though this panel is much broader.] Off-panel voice: Is this a normal bug, or one of those horrifying ones that prove your whole project is broken beyond repair and should be burned to the ground?
[Zoom in on Cueball's head and upper torso.] Cueball: It's a normal one this time, I promise. Off-panel voice: OK, what's the bug?
[Back to a view similar to the first panel where Cueball has turned towards the computer and points at the screen with one hand.] Cueball: The server crashes if a user's password is a resolvable URL. Off-panel voice: I'll get the lighter fluid.

Cueball asks if an off-panel character can look at his bug report. The person asks if it's a "normal one," and not a "horrifying" one which proves that the entire project is "broken beyond repair and should be burned to the ground." This implies that there have been reports of the "horrifying" variety in the past.
Cueball promises that it is a normal one but it turns out that the server crashes when a user's password is a resolvable URL, which implies that the server is in some way attempting to resolve passwords as if they were URLs. A resolvable URL is one that is syntactically correct and refers to a find-able and accessible resource on the internet (i.e. does not return a 404 error or equivalent when resolved). Therefore a resolvable URL is a fully qualified domain name or a valid IP address that points to a valid server, and it can optionally specify a resource that exists on that server. Normally there is no reason for a system to treat a password as if it were a URL — and testing if a password is a resolvable URL would be a horrible thing to do as it would involve sending the password over the internet in a (at the time the comic was written) most likely completely unencrypted format.
Also, Cueball specifically states that the server is crashing, rather than his application. While this could be an example of misused terminology on the part of Cueball or Randall, given Cueball's history (for example causing the most basic console commands to fail in 1084: Server Problem or other tech issues as seen in 1586: Keyboard Problems ) his choice of terms is probably accurate. In the context of web services the server refers to either the computer itself or the program that responds to web requests and executes the user's (i.e. Cueball's) application. Cueball would be in charge of building the application. The importance of this distinction is that a typical system has safe guards in place at many levels to prevent a misbehaving application from crashing anything other than itself. So for his application to crash the server (either the computer itself or the server software hosting his application) would require his application to be operating in a way far outside of the normal, which has been the case for Cueball in previous comics. Alternatively, the project might include its own server software without the safeguards. In either case it is clear that Cueball's issue is far from normal, for which reason the off-panel person gives up and decides that burning the project to the ground is the only solution, telling Cueball I'll get the lighter fluid .
In the title text, another two issues with Cueball's program are mentioned, together with a possible solution that would fix all three problems at once. The second problem is a unicode-handling bug in the URL request library, and the third is that the passwords are stored unsalted. The proposed solution is to salt the passwords with emoji (unicode, multi-byte characters), which is claimed to solve all three issues at once. Salting passwords means that random characters are added to the password before it is cryptographically-secured and stored in the database. Salting increases security in the event that the database is compromised by ensuring that users with the same password will not have the same password hash. This makes some attacks that can be used to crack hash databases, such as rainbow tables , effectively impossible. Salting passwords with emoji can potentially "fix" these bugs in different ways. First, emoji and other unicode characters are not valid characters in URLs. As a result the salted-passwords will no longer be resolvable URLs. This will presumably circumvent (but not actually fix) the bug that causes the server to crash. In addition, the passwords will now be salted, increasing security. There is no obvious way that this would actually fix a unicode-handling bug in the URL request library. Given Cueball's general approach to problems like this, the best explanation is probably that he hasn't "fixed" the bug but rather that it is no longer a bug because he is relying on its behavior to help fix these other issues, i.e. the classic it's not a bug, it's a feature .
The title text shows that his general approach to problems is not to actually fix bugs but to work around them and even rely on them for other behavior. This approach to software development makes for terrible code, which is likely how Cueball got into this trouble in the first place. Therefore the title text shows that he still has yet to learn from his mistakes, further supporting the suggestion to just burn the whole thing down.
In the title text of the first, using emoji in variable names is mentioned. Emoji has since then become a recurrent theme on xkcd.
In 1349: Shouldn't Be Hard , Cueball is also programming and finding it very difficult, although he thinks it should be easy. An off-panel person suggests burning the computer down with a blowtorch, much like the off-panel person in this one suggests burning the whole project (including the computer) to the ground with lighter fluid. In the next comic, with multiple storylines 1350: Lorenz , one story line results in a computer being burned with a blow torch .
Interestingly, the 2021 vulnerability Log4Shell could be triggered when a specially crafted URL was logged with the Log4j framework. This could lead to a crash (as in the comic) or the computer being taken over by the attacker.  However, the contents of a password field should never be logged, so this still would indicate a major problem with the design of Cueball's project.
[Cueball sits at his desk in front of his computer leaning back and turning away from it to speak to a person off-panel.] Cueball: Can you take a look at the bug I just opened? Off-panel voice: Uh oh.
[Zoom out and pan to show only Cueball sitting on his chair facing away from the computer, which is now off-panel. The person speaking to him is still of panel even though this panel is much broader.] Off-panel voice: Is this a normal bug, or one of those horrifying ones that prove your whole project is broken beyond repair and should be burned to the ground?
[Zoom in on Cueball's head and upper torso.] Cueball: It's a normal one this time, I promise. Off-panel voice: OK, what's the bug?
[Back to a view similar to the first panel where Cueball has turned towards the computer and points at the screen with one hand.] Cueball: The server crashes if a user's password is a resolvable URL. Off-panel voice: I'll get the lighter fluid.
