package bonsai

  1. Overview
  2. Docs
package bonsai
Legend:
Page
Library
Module
Module type
Parameter
Class
Class type
Source

Module Uri_parsing.Percent_encoding_behaviorSource

Sourcetype t =
  1. | Legacy_incorrect
  2. | Correct

TLDR: New apps should always choose Correct.

TLDR pt2: Updating old apps to Correct is also recommended. However, if the app also does its own percent encoding, additional testing should be done to ensure backwards compatibility.

The first implementation of bonsai_web_ui_url/uri_parsing originally mishandled pct encoding (e.g. sometimes " " got translated to %20, but when translated back, it sometimes translated back to "%20" instead of to " ")

Changing this behavior is ~generally _not_ a breaking change, but could be a breaking change in the following contrived situation:

1. Your app handled the pct_encoding bug, but defensively doing pct encoding/decoding. 2. Correcting the behavior on uri_parsing still results in your parsing being able to parse/unparse url's, but the change in behavior is that now things are percent encoded twice, but your app should still be able to decode it correctly as it'd also be decoded twice. 3. The change in behavior is that if you had an _already existing_ URL whose value correct happens to look like a pct_encoded string, and you then pct_encoded it once (now it looks like a pct_encoded string twice), before you only decoded it one step, but after the change you would've decoded it twice.

New links are not affected by this; only old links are.

We expect this situation to be rare, but (in a contrived scenario) an app's links could generate links that look pct_encoded all the time, and if your users sent a lot of links _all_ of the old links would stop working.

If your app generates "normal"-looking links (without %'s in them or anything that looks to be %-encoded). It is totally safe/no changes in behavior (other than you should now be able to correctly put % in the path) are expected.