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
At the moment HttpServerRequestImpl and Http2ServerRequestImpl are both automatically decoding the query string values. This leads to the issue that the following URIs are equivalent:
http://example.com/foo?bar=restaurant%2C24h
vs
http://example.com/foo?bar=restaurant,24h
The purpose of reserved characters is to provide a set of delimiting
characters that are distinguishable from other data within a URI.
URIs that differ in the replacement of a reserved character with its
corresponding percent-encoded octet are not equivalent.
This is an issue we experience currently when adding semantics to reserved characters, that is why RFC-3986 states in section 2.4:
When a URI is dereferenced, the components and subcomponents
significant to the scheme-specific dereferencing process (if any)
must be parsed and separated before the percent-encoded octets within
those components can be safely decoded, as otherwise the data may be
mistaken for component delimiters.
Currently there is no way how that can be done as the corresponding map and methods are all private.
Please support a way to implement the URI component decode in a custom function. I guess the way it is done currently will be sufficient for 99% of all use cases, but for some use cases there need to be a way to add semantics to reserved characters.
Our current hack is that we, very early, set in the private params property using the Unsafe class and parsing the uri by our self (so hacking private members). If you have any other solution that I missed, please let me know.
We currently use vert.x version 3.5.1
The text was updated successfully, but these errors were encountered:
At the moment HttpServerRequestImpl and Http2ServerRequestImpl are both automatically decoding the query string values. This leads to the issue that the following URIs are equivalent:
However, following RFC-3986 section 2.2 they are not:
This is an issue we experience currently when adding semantics to reserved characters, that is why RFC-3986 states in section 2.4:
Currently there is no way how that can be done as the corresponding map and methods are all private.
Please support a way to implement the URI component decode in a custom function. I guess the way it is done currently will be sufficient for 99% of all use cases, but for some use cases there need to be a way to add semantics to reserved characters.
Our current hack is that we, very early, set in the private params property using the Unsafe class and parsing the uri by our self (so hacking private members). If you have any other solution that I missed, please let me know.
We currently use vert.x version 3.5.1
The text was updated successfully, but these errors were encountered: