refactor: remove deprecations in HTTP

[paulbalandan]

Description
Sending this early to get the #10000 slot. 😂

This is not yet complete, but initially there are quite breaking changes:

• Removed the deprecated assumption that URIs with the same host as baseURL should be relative to the project's configuration (deprecated by Internal URI handling #4646 and reinforced in fix: forceGlobalSecureRequests break URI schemes other than HTTP #5730)
• URI::setSilent() is removed, meaning it will always throw exceptions on invalid URIs instead of continuing.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[michalsn]

Sending this early to get the #10000 slot. 😂

Haha, love the dedication 😆

I'm a little concerned about removing URI::setSilent(). Given how commonly it's used, this might be more disruptive than expected.

[paulbalandan]

I'm a little concerned about removing URI::setSilent(). Given how commonly it's used, this might be more disruptive than expected.

The deprecation was made in #7252 , mainly because it's not in PSR-7. Do you mean to "un-deprecate" it?

[michalsn]

Well, the reason in the comment ("Method not in PSR-7") isn't very fortunate, because PSR-7 allows extra methods.

The real problem is immutability and hidden behavioral state.

Since setSilent() has existed for a long time and occasionally comes up on Slack, I would prefer postponing removal until v5 to avoid unnecessary complaints.

[paulbalandan]

Okay, I'll retain it and add a hard deprecation notice on it. For the *Silent tests, are you fine with removing them though?

[michalsn]

Yes, thank you!

[michalsn]

This is also problematic. In the constructor, we call $uri->useRawQueryString(), which prevents the use of parse_str(). This is important because parse_str() would modify query parameters - for example, converting http://example.com/?foo.bar=baz into foo_bar=baz.

[paulbalandan]

Hmm, since useRawQueryString() is not in PSR 7, how about putting that as the 2nd argument in URI's constructor, call here with true, then deprecate useRawQueryString()?

[michalsn]

I'm fine with adding this to the constructor. Deprecating useRawQueryString() would also make sense, as the parsing behavior would be fixed at construction time. Although I'm not sure if this would be a problem in the long run, probably no one is using this feature elsewhere.

[paulbalandan]

I figured in the docs, it can be called before using setQueryArray(), so making it constructor-only seems an unnecessary break. Instead, I just called useRawQueryString() immediately after instantiation.

[michalsn]

This will not work if the baseURI has a query. This is too late, as the constructor has already run through setQuery().