chore: update Unleash JS client

[Tymek]

About the changes

Bump unleash-proxy-client to 3.7.3

[ahmetacer5]

Hi,

First off, thanks for all the work you put into maintaining @unleash/proxy-client-react!

We recently upgraded to latest version 4.5.2 and ran into an issue where the new HTTP headers introduced in this release caused our apps to break due to restrictions on our reverse proxy.

Since this change required us to update our proxy rules, it feels more like a breaking change rather than a patch or minor update. Based on SemVer, we expected a patch release to be fully backward-compatible, so this caught us off guard.

Would love to get your thoughts on:

How you approach versioning for changes like this
Whether similar updates in the future could be considered for a minor or major version bump
If there’s a way to make this kind of behavior configurable to avoid unexpected issues
Appreciate your time, and thanks again for all the work on this project!

The message above was improved with LLM, but reflects my opinions correctly :)

[kwasniew]

Hi @ahmetacer5 Sorry to hear about the problems. Let me explain the thinking behind those version changes so that we can come up with an action plan for future improvements. The new experimental HTTP headers got introduced in 4.5.0 (after 4.4.x) because it was a new feature so we decided to make a minor version bump (middle version). In 4.5.x we iterated on small fixes to those headers so they were patch version bumps. HTTP itself is designed with Robustness Principle (“be forgiving in what you receive”) in mind (https://en.wikipedia.org/wiki/Robustness_principle) allowing clients and network proxies to ignore things that they are not interested in. This removes common problems from oldschool binary protocols like CORBA/Java RMI etc and allows the client and server to be upgraded independently. In your proxy configuration can you have rules to allow Unleash headers (like Unleash-* or X-Unleash-*) without having to manually add them every time there’s a change? Would this work for you?

[ahmetacer5]

Hi @ahmetacer5 Sorry to hear about the problems. Let me explain the thinking behind those version changes so that we can come up with an action plan for future improvements. The new experimental HTTP headers got introduced in 4.5.0 (after 4.4.x) because it was a new feature so we decided to make a minor version bump (middle version). In 4.5.x we iterated on small fixes to those headers so they were patch version bumps. HTTP itself is designed with Robustness Principle (“be forgiving in what you receive”) in mind (https://en.wikipedia.org/wiki/Robustness_principle) allowing clients and network proxies to ignore things that they are not interested in. This removes common problems from oldschool binary protocols like CORBA/Java RMI etc and allows the client and server to be upgraded independently. In your proxy configuration can you have rules to allow Unleash headers (like Unleash-* or X-Unleash-*) without having to manually add them every time there’s a change? Would this work for you?

Thanks for your kind reply Mateusz, I totally understand just wanted to give you heads up.

Your suggestion sounds great if you are going to keep same prefix pattern that can work for us.

Have a great day!

[kwasniew]

@ahmetacer5 Thanks! FYI, for now we settled on the Unleash-* prefix (case insensitive) for our headers since X- headers are discouraged by the spec.

[ahmetacer5]

@ahmetacer5 Thanks! FYI, for now we settled on the Unleash-* prefix (case insensitive) for our headers since X- headers are discouraged by the spec.

Sounds great yes, better not to consider X- anymore.