You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In fact, one of the reasons for introducing UriComponents in Spring Framework was because java.net.URI had known encoding issues, which meant that we had to create our own abstraction that did follow the related RFCs. And as mentioned above, accepting the % is one thing, but it really should be encoded on output, in accordance with RFC 6874.
(The % point issue is relative to Leshan issue : #1580 (comment))
The text was updated successfully, but these errors were encountered:
Since we introduce the new transport layer abstraction, we identify endpoint by
URI
usingjava.net.URI
.There is some argument to replace this by a
String
or a dedicated new class (EndpointURI
?).Here is a list of those arguments :
java.net.URI
use lot of memory : Should Registration be strictly tied to a server endpoint ? #1415 (comment)java.net.URI
is full of not fixed bug and doesn't support RFC3986 and RFC3987 : https://cr.openjdk.org/~dfuchs/writeups/updating-uri/java.net.URI
is overkill, currently we only needscheme
,host
andport
.Spring project goes to the conclusion that URI class has lot of issue and should be replaced :
(The
%
point issue is relative to Leshan issue : #1580 (comment))The text was updated successfully, but these errors were encountered: