The current core implementation does not define a proper contract for case insensitivity leading to all sorts of bugs, e.g.
JENKINS-22057
JENKINS-12607
JENKINS-3218
JENKINS-9771
JENKINS-6377
JENKINS-20125
JENKINS-18009
Also there are a lot of issues showing a fundamental misunderstanding of why Jenkins originally used a semi-case insensitive username... (hint the real reason is because windows filesystem is case insensitive)
People seem to think that user ids are case insensitive... despite
- unix logins being case sensitive
- email addresses being case sensitive (yes they are allowed to be... read the RFC... the destination server is allowed to treat them as case sensitive... though the RFC does say a polite version of "only a fool would actually do that" it is allowed by the spec, so you cannot assume that foo@acme.org is the same person as Foo@acme.org... you can however assume that foo@acme.org and foo@ACME.ORG are the same person as is foo@aCmE.OrG because domain names are not case sensitive)
As such, without a plugable strategy the case sensitive/insensitivity of Jenkins is fundamentally broken.
Originally reported by
stephenconnolly, imported from: Provide an extension point to define user id case sensitivity contract
- status: Resolved
- priority: Major
- component(s): core
- label(s): api
- resolution: Fixed
- resolved: 2014-05-22T20:37:27+00:00
- votes: 1
- watchers: 9
- imported: 2025-11-24
Raw content of original issue
The current core implementation does not define a proper contract for case insensitivity leading to all sorts of bugs, e.g.
JENKINS-22057
JENKINS-12607
JENKINS-3218
JENKINS-9771
JENKINS-6377
JENKINS-20125
JENKINS-18009
Also there are a lot of issues showing a fundamental misunderstanding of why Jenkins originally used a semi-case insensitive username... (hint the real reason is because windows filesystem is case insensitive)
People seem to think that user ids are case insensitive... despite
- unix logins being case sensitive
- email addresses being case sensitive (yes they are allowed to be... read the RFC... the destination server is allowed to treat them as case sensitive... though the RFC does say a polite version of "only a fool would actually do that" it is allowed by the spec, so you cannot assume that foo@acme.org is the same person as Foo@acme.org... you can however assume that foo@acme.org and foo@ACME.ORG are the same person as is foo@aCmE.OrG because domain names are not case sensitive)
As such, without a plugable strategy the case sensitive/insensitivity of Jenkins is fundamentally broken.
The current core implementation does not define a proper contract for case insensitivity leading to all sorts of bugs, e.g.
JENKINS-22057JENKINS-12607
JENKINS-3218JENKINS-9771JENKINS-6377JENKINS-20125JENKINS-18009Also there are a lot of issues showing a fundamental misunderstanding of why Jenkins originally used a semi-case insensitive username... (hint the real reason is because windows filesystem is case insensitive)
People seem to think that user ids are case insensitive... despite
As such, without a plugable strategy the case sensitive/insensitivity of Jenkins is fundamentally broken.
Originally reported by
stephenconnolly, imported from: Provide an extension point to define user id case sensitivity contract
Raw content of original issue
As such, without a plugable strategy the case sensitive/insensitivity of Jenkins is fundamentally broken.