[JENKINS-75278] User pages for users with '\' in the user name fail after upgrading to 2.479.1

[jenkins-infra-bot]

Note that this ticket is somehow related to JENKINS-73129

How to reproduce

Given a Jenkins configured to use LDAP as Security Realm.

Given a user with a `\` in the username.

What is the behavior

The user is allowed to sign-in:

---

But the user page gives this error:

And the drop down menu is broken

What is the expected behavior

Here is the expected behavior (Jenkins 2.461)

 

 

 

---

Originally reported by jmdesprez, imported from: User pages for users with '\' in the user name fail after upgrading to 2.479.1

• assignee: rsandell
• status: Closed
• priority: Minor
• component(s): core
• label(s): 2.492.3-fixed
• resolution: Fixed
• resolved: 2025-03-12T17:11:52+00:00
• votes: 0
• watchers: 5
• imported: 2025-11-24

Raw content of original issue

Note that this ticket is somehow related to JENKINS-73129
How to reproduce

Given a Jenkins configured to use LDAP as Security Realm.

Given a user with a `\` in the username.
What is the behavior

The user is allowed to sign-in:





But the user page gives this error:



And the drop down menu is broken


What is the expected behavior

Here is the expected behavior (Jenkins 2.461)



 



 

 

7 attachments

• image-2025-02-13-12-00-28-967.png

  

• image-2025-02-13-12-01-23-199.png

  

• image-2025-02-13-12-02-10-784.png

  

• image-2025-02-13-12-03-48-640.png

  

• image-2025-02-13-12-08-18-947.png

  

• image-2025-02-13-12-08-50-212.png

  

• image-2025-02-13-12-09-27-739.png

  

[jenkins-infra-bot]

• Remote links associated with this issue:

  • Jetty issue #​12809
  • jenkinsci/jenkins#​10344
  • jenkinsci/winstone#​426
  • jenkinsci/jenkins-test-harness#​930
  • jenkinsci/maven-hpi-plugin#​720
  • jenkinsci/stapler#​649

[jenkins-infra-bot]

basil:

• Original comment link
• Raw content of original comment:

  We consistently use UriCompliance.LEGACY in
  
  jenkins-test-harness/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java:        config.setUriCompliance(UriCompliance.LEGACY);
  jenkins-test-harness/src/main/java/org/jvnet/hudson/test/JenkinsRule.java:        config.setUriCompliance(UriCompliance.LEGACY);
  maven-hpi-plugin/src/main/java/org/jenkinsci/maven/plugins/hpi/RunMojo.java:        hc.setUriCompliance(UriCompliance.LEGACY);
  stapler/core/src/test/java/org/kohsuke/stapler/test/JettyTestCase.java:        hc.setUriCompliance(UriCompliance.LEGACY);
  winstone/src/main/java/winstone/Http2ConnectorFactory.java:            https_config.setUriCompliance(UriCompliance.LEGACY);
  winstone/src/main/java/winstone/ServerConnectorBuilder.java:        hc.setUriCompliance(UriCompliance.LEGACY);
  
  
  which is documented as follows:
  LEGACY compliance mode that models Jetty-9.4 behavior
  Yet this compliance mode contains https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/http/UriCompliance.Violation.html#SUSPICIOUS_PATH_CHARACTERS as described in https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0.html#uri-path-canonicalization which does not actually model legacy Jetty behavior (as claimed in the documentation); rather, the behavior is more strict than the legacy Jetty behavior. Suggest reporting this issue to the Jetty developers.
  

We consistently use UriCompliance.LEGACY in

jenkins-test-harness/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java:config.setUriCompliance(UriCompliance.LEGACY);
jenkins-test-harness/src/main/java/org/jvnet/hudson/test/JenkinsRule.java:config.setUriCompliance(UriCompliance.LEGACY);
maven-hpi-plugin/src/main/java/org/jenkinsci/maven/plugins/hpi/RunMojo.java:hc.setUriCompliance(UriCompliance.LEGACY);
stapler/core/src/test/java/org/kohsuke/stapler/test/JettyTestCase.java:hc.setUriCompliance(UriCompliance.LEGACY);
winstone/src/main/java/winstone/Http2ConnectorFactory.java:    https_config.setUriCompliance(UriCompliance.LEGACY);
winstone/src/main/java/winstone/ServerConnectorBuilder.java:hc.setUriCompliance(UriCompliance.LEGACY);

which is documented as follows:

LEGACY compliance mode that models Jetty-9.4 behavior

Yet this compliance mode contains https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/http/UriCompliance.Violation.html#SUSPICIOUS_PATH_CHARACTERS as described in https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0.html#uri-path-canonicalization which does not actually model legacy Jetty behavior (as claimed in the documentation); rather, the behavior is more strict than the legacy Jetty behavior. Suggest reporting this issue to the Jetty developers.

[jenkins-infra-bot]

basil:

• Original comment link
• Raw content of original comment:

  Pending Review UriCompliance.LEGACY and its omission of SUSPICIOUS_PATH_CHARACTERS jetty/jetty.project#12809 suggest replacing the occurrences of UriCompliance.LEGACY mentioned above with UriCompliance.LEGACY.with("custom", UriCompliance.Violation.SUSPICIOUS_PATH_CHARACTERS) as in https://github.com/jetty/jetty-examples/blob/ff76268f75d7cc39945b0bf97059381bb5f27cc9/embedded/ee10-servlet-ambiguous-paths/src/main/java/examples/EmbedMe.java#L38 (and adding setDecodeAmbiguousURIs(true) as in https://github.com/jetty/jetty-examples/blob/ff76268f75d7cc39945b0bf97059381bb5f27cc9/embedded/ee10-servlet-ambiguous-paths/src/main/java/examples/EmbedMe.java#L49).
  

Pending jetty/jetty.project#12809 suggest replacing the occurrences of UriCompliance.LEGACY mentioned above with UriCompliance.LEGACY.with("custom", UriCompliance.Violation.SUSPICIOUS_PATH_CHARACTERS) as in https://github.com/jetty/jetty-examples/blob/ff76268f75d7cc39945b0bf97059381bb5f27cc9/embedded/ee10-servlet-ambiguous-paths/src/main/java/examples/EmbedMe.java#L38 (and adding setDecodeAmbiguousURIs(true) as in https://github.com/jetty/jetty-examples/blob/ff76268f75d7cc39945b0bf97059381bb5f27cc9/embedded/ee10-servlet-ambiguous-paths/src/main/java/examples/EmbedMe.java#L49).

[jenkins-infra-bot]

rsandell:

• Original comment link
• Raw content of original comment:

  Hmm
  
  setDecodeAmbiguousURIs(true) seems to only be available in jetty servlet ee10 while winstone seems to be using ee9?
  

Hmm

setDecodeAmbiguousURIs(true) seems to only be available in jetty servlet ee10 while winstone seems to be using ee9?

[jenkins-infra-bot]

basil:

• Original comment link
• Raw content of original comment:

  Yeah, the call to setDecodeAmbiguousURIs can simple be omitted on EE 9, or perhaps included commented-out with a comment to uncomment it when we migrate from EE 9 to EE 10. I've already prototyped that migration and plan to work on it more in the coming weeks (right now I need to reimplement WebSocket, which isn't working at all on EE 10).
  

Yeah, the call to setDecodeAmbiguousURIs can simple be omitted on EE 9, or perhaps included commented-out with a comment to uncomment it when we migrate from EE 9 to EE 10. I've already prototyped that migration and plan to work on it more in the coming weeks (right now I need to reimplement WebSocket, which isn't working at all on EE 10).

[jenkins-infra-bot]

rsandell:

• Original comment link
• Raw content of original comment:

  [JENKINS-75278] User pages for users with '\' in the user name fail after upgrading to 2.479.1 #10344
  

#10344