search

hal4j / uritemplate

Java implementation of RFC 6570 (URI template)
Apache License 2.0
3 stars 0 forks source link

The asterisk as a reserved char should not be pсе-encoded #6

Closed C06A closed 11 months ago

C06A commented 1 year ago

As I am reading RFC-6570 the asterisk is one of the reserved char and as such should not be encoded only in Reserved, and Fragment Expansions. It seems it is not encoded in Simple String and Path Expansions, which I tested.

Other reserved chars work correct.

ivan-gammel commented 1 year ago

@C06A this ticket has rather interesting story behind it. Current implementation uses java.net.URLEncoder for encoding, which does not consider asterisk as a reserved character, because in 1996-1998 it was not considered as such. That code was written even before RFC 2396 was published (the standard referred to in source code comments of modern JDKs).

Some time in 2003-2004 Tim Berners-Lee and his co-authors changed their mind (compare [1] and [2]) and changed the draft of upcoming specification RFC 3986, where they moved asterisk from unreserved to reserved characters. URI Template specification RFC 6570 explicitly refers to RFC 3986, so you are right, it probably makes sense to fix it. The fix however will be a breaking change for the current implementation that will not be compatible with java.net.URLEncoder, so we should think carefully about what is the right approach.

Do you know any specific example of when asterisk is used in any part of the URI? In which scenarios it can be passed to the URI template as a parameter value or part of it?

[1] https://datatracker.ietf.org/doc/html/draft-fielding-uri-rfc2396bis-03 [2] https://datatracker.ietf.org/doc/html/draft-fielding-uri-rfc2396bis-04

ivan-gammel commented 11 months ago

PCT encoding re-implemented based on RFC 6570, rather than older URI spec used by Java.