Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in params() method / automatic URL component decode #380

Open
xeus2001 opened this issue Jun 6, 2018 · 0 comments
Open

Bug in params() method / automatic URL component decode #380

xeus2001 opened this issue Jun 6, 2018 · 0 comments

Comments

@xeus2001
Copy link

xeus2001 commented Jun 6, 2018

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

However, following RFC-3986 section 2.2 they are not:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant