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

Feature Request: Option for case sensitivity #1214

Closed
lambertkuang opened this issue Feb 28, 2017 · 12 comments
Closed

Feature Request: Option for case sensitivity #1214

lambertkuang opened this issue Feb 28, 2017 · 12 comments

Comments

@lambertkuang
Copy link

The default option for case sensitivity in path-to-regexp is false and I couldn't find an option to set it from a new Vue router instance. I'm trying to redirect some old paths in a project to new ones, and some of these new paths are just capitalized versions of the old, like /all-stores to /All-Stores but this causes an infinite redirect loop with the current setting.

@posva
Copy link
Member

posva commented Feb 28, 2017

Hello! URIs are case insensitive (even if servers can handle them differently), so there's no reason to add an option to allow creating case sensitive routes to vue-router. It'll make things confusing and allow people to create routes that are wrong.

Although schemes are case-
insensitive, the canonical form is lowercase and documents that
specify schemes must do so with lowercase letters.

(https://tools.ietf.org/html/rfc3986#section-3.1)

@posva posva closed this as completed Feb 28, 2017
@smitt04
Copy link
Contributor

smitt04 commented Feb 28, 2017

Hey @posva The specification you posted there is only talking about the scheme (http, ftp, ws, etc...) According to the rfc spec the scheme and host are case insensitive, but the path portion of the URI is supposed to be case sensitive.

From https://tools.ietf.org/html/rfc3986#section-6.2.2.1

For all URIs, the hexadecimal digits within a percent-encoding
triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore
should be normalized to use uppercase letters for the digits A-F.

When a URI uses components of the generic syntax, the component
syntax equivalence rules always apply; namely, that the scheme and
host are case-insensitive and therefore should be normalized to
lowercase. For example, the URI HTTP://www.EXAMPLE.com/ is
equivalent to http://www.example.com/. The other generic syntax
components are assumed to be case-sensitive unless specifically
defined otherwise by the scheme.

According to that the scheme, host and the hexidecimal parts of the path are case insensitive, but all other components should be case sensitive.

@fnlctrl
Copy link
Member

fnlctrl commented Feb 28, 2017

but all other components should be case sensitive.

Sorry, but there is no such statement in the RFC.

@lambertkuang
Copy link
Author

That link above (https://tools.ietf.org/html/rfc3986#section-6.2.2.1) does say the other components are assumed to be case-sensitive.

The other generic syntax
components are assumed to be case-sensitive unless specifically
defined otherwise by the scheme (see Section 6.2.3).

And Section 6.2.3 (https://tools.ietf.org/html/rfc3986#section-6.2.3) has no mention of the path, so we can assume it to be case sensitive.

@cthayer
Copy link

cthayer commented Feb 28, 2017

I see that statement in the RFC...

And nothing in the HTTP 1.1 RFC (https://tools.ietf.org/html/rfc7230#section-2.7) states otherwise, so it seems to me that the path should be case sensitive.

GoogleBot also treats paths as case sensitive so there's some accepted industry practices as well.

@fnlctrl
Copy link
Member

fnlctrl commented Feb 28, 2017

assumed to be isn't equivalent of required to be(or should be).
Case sensitivity for urls is generally decided by implementations as of today. Most sites (including Github) treats urls as case-insensitive. There is no practical advantage of using case sensitive urls - users simply don't bother to type cased urls in to the browser.

@smitt04
Copy link
Contributor

smitt04 commented Feb 28, 2017

So if you are saying that assumed to be is not the same as required to be and should be decided by the implementation. Then it seems to make more sense to allow the developers to decide if they want their URIs to be case sensitive or insensitive, not the library's.

@cthayer
Copy link

cthayer commented Feb 28, 2017

Case sensitivity for urls is generally decided by implementations

I would think this reasoning is exactly why case sensitivity in urls should be an option in the vue router.

That way the implementation can decide if urls should be case sensitive.

IMHO the application using the framework is the implementation and should make implemenation decisions. As the framework, vue should empower the application to make these types of decisions.

@fnlctrl
Copy link
Member

fnlctrl commented Feb 28, 2017

Well, PRs are always welcome.

@posva
Copy link
Member

posva commented Feb 28, 2017

Paths should not be case sensitive but they can. On the other hand, query params like ?query=Hello are always case sensitive.
I overlooked the first thing and thought they couldn't, sorry for that. Makes sense to support it, indeed.

About the implementation: an SPA is half of the implementation, the other half being the server. If a user activates the case-sensitive paths, he also needs to make sure the server treats them correspondingly. But I'm pretty sure that's the default behaviour. For instance, Google cares about it while Stack Overflow doesn't.

If you want to submit a PR, you need to add an option like caseSensitive or a pathToRegexpOptions that can contain other attributes like strict (looks like the only one that is useful too) to the RouteConfig type https://github.com/vuejs/vue-router/blob/dev/flow/declarations.js#L32 and then pass it down until getRouteRegex. I think the caseSensitive option looks better. Hope it helps.

@smitt04
Copy link
Contributor

smitt04 commented Feb 28, 2017

Thanks, i will work on a PR

smitt04 pushed a commit to sazze/vue-router that referenced this issue Feb 28, 2017
…RegexpOptions to RouteRecord. Used to support senstive matches and pass along more options to pathToRegexp. vuejs#1214
@smitt04
Copy link
Contributor

smitt04 commented Feb 28, 2017

Submitted PR #1215

posva pushed a commit to sazze/vue-router that referenced this issue May 17, 2017
…RegexpOptions to RouteRecord. Used to support senstive matches and pass along more options to pathToRegexp. vuejs#1214
yyx990803 pushed a commit that referenced this issue Jun 16, 2017
* added caseSensitive and pathToRegexpOptions to RouteConfig and pathToRegexpOptions to RouteRecord. Used to support senstive matches and pass along more options to pathToRegexp. #1214

* changed test for /FooBar to redirect to /FOOBAR

* fixed tests and added 2 tests for case sensitive redirects

* added some route-matching tests

* Update create-route-map.js

* Update route-matching.js

* Update code to use caseSensitive option

* Add unit test for caseSensitive

* Add test for pathToRegexpOptions in route

* Fix flow typings

* Add ts types

* Remove old test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants