Removed decimals in boundary multipart form data

[rubenrcdev]

The polyfill library wasn't working for me because the boundary had decimals.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[mstoykov]

Hi @rubenrcdev, thank you for the PR 🙇

Can you please provide an example that showcases your issue. AFAIK '.' is an allowed symbol in the boundary. And it seems to work for other users of the library in the past.

Maybe the server used in your case has a problem with it. Can we know what it is?

[Copilot]

Pull Request Overview

This PR fixes an issue with multipart form data boundary generation by removing decimal points from the random boundary string. The polyfill library was failing due to the presence of decimals in the boundary.

• Modified boundary generation to remove decimal points by using substring(2) on the random string

[Copilot]

The comment should be updated to explain why substring(2) is used to remove the '0.' prefix from Math.random().toString(36), as this is a non-obvious implementation detail that addresses a specific compatibility issue.

Suggested change

	// form's contents.
	// form's contents.
	// The substring(2) removes the '0.' prefix from Math.random().toString(36),
	// ensuring the boundary string is valid and compatible with multipart/form-data.

[codebien]

Hey @rubenrcdev,
as @mstoykov the . char seems to be allowed from the RFC. Any char from US-ASCII 7-bit charset should be compliant.

I'm closing this for now, feel free to provide additional documentation and we might re-evaluate this decision.

Note, the CLA is required to be signed to get any pull request merged.