[jira] [Commented] (FELIX-5143) Gogo Command bundle should not include org.osgi.service.log classes
[ https://issues.apache.org/jira/browse/FELIX-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461337#comment-16461337 ] Xavier Fournet commented on FELIX-5143: --- [~gnt] The fix version is stuck on gogo.command-0.18.0 which seems outdated since next version is gogo.command-1.1.0 Could the fix version be updated to gogo.command-1.1.0 ? and i hope that finally this fix will be included :) > Gogo Command bundle should not include org.osgi.service.log classes > --- > > Key: FELIX-5143 > URL: https://issues.apache.org/jira/browse/FELIX-5143 > Project: Felix > Issue Type: Bug > Components: Gogo Command >Reporter: Xavier Fournet >Priority: Major > Fix For: gogo.command-0.18.0 > > > The classes of org.osgi.service.log are present in the Gogo command jar files. > The bundle should instead import this package. It seems that there was a > confusion between Export-Package and Import-Package in the BND directives in > pom.xml -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5143) Gogo Command bundle should not include org.osgi.service.log classes
[ https://issues.apache.org/jira/browse/FELIX-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394526#comment-16394526 ] Xavier Fournet commented on FELIX-5143: --- I rebased and improved the pull request. Could you please review it and include it into next release please ? > Gogo Command bundle should not include org.osgi.service.log classes > --- > > Key: FELIX-5143 > URL: https://issues.apache.org/jira/browse/FELIX-5143 > Project: Felix > Issue Type: Bug > Components: Gogo Command >Reporter: Xavier Fournet >Priority: Major > Fix For: gogo.command-0.18.0 > > > The classes of org.osgi.service.log are present in the Gogo command jar files. > The bundle should instead import this package. It seems that there was a > confusion between Export-Package and Import-Package in the BND directives in > pom.xml -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (FELIX-5574) When detecting an unknow Windows OS name, provides a suitable default value for org.osgi.framework.os.name
[ https://issues.apache.org/jira/browse/FELIX-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Fournet closed FELIX-5574. - It's ok, thanks you > When detecting an unknow Windows OS name, provides a suitable default value > for org.osgi.framework.os.name > -- > > Key: FELIX-5574 > URL: https://issues.apache.org/jira/browse/FELIX-5574 > Project: Felix > Issue Type: Improvement > Components: Framework >Reporter: Xavier Fournet >Assignee: Karl Pauls >Priority: Minor > Fix For: framework-5.6.4 > > > When the system property os.name return a Windows OS name that is not > recognized by > org.apache.felix.framework.util.manifestparser.NativeLibraryClause#normalizeOSName > then it return "win" as a fallback value. > However this "win" value is not something valid for the > org.osgi.framework.os.name property name (cf > https://www.osgi.org/developer/specifications/reference/) > Changing the fallback value to "win32" would be better so it would allow most > of the JNI library to be loaded. > This would allow smooth support of future windows platform, for example for > Windows Server 2016 with JDK9 (or JDK8 when > https://bugs.openjdk.java.net/browse/JDK-8159948 will be fix on it) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5574) When detecting an unknow Windows OS name, provides a suitable default value for org.osgi.framework.os.name
[
https://issues.apache.org/jira/browse/FELIX-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978876#comment-15978876
]
Xavier Fournet commented on FELIX-5574:
---
As expected, the latest JDK8 version now recognize correctly Windows Server
2016 leading Felix to fall again this trap.
Repro case on Windows Server 2016 + Felix 5.6.2
With JDK 1.8.0_121 it's working correctly
{noformat}
C:\work\felix-framework-5.6.2>..\jdk-1.8.0_121\bin\java.exe -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
C:\work\felix-framework-5.6.2>..\jdk-1.8.0_121\bin\java.exe -jar bin\felix.jar
Welcome to Apache Felix Gogo
g! context:getProperty os.name
Windows NT (unknown)
g! context:getProperty org.osgi.framework.os.name
windowsnt
g! install
http://central.maven.org/maven2/org/xerial/snappy/snappy-java/1.1.2.6/snappy-java-1.1.2.6.jar
Bundle ID: 7
g! start 7
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active |0|System Bundle (5.6.2)|5.6.2
1|Active |1|jansi (1.14.0)|1.14.0
2|Active |1|JLine (3.0.1)|3.0.1
3|Active |1|Apache Felix Bundle Repository (2.0.8)|2.0.8
4|Active |1|Apache Felix Gogo Command (1.0.2)|1.0.2
5|Active |1|Apache Felix Gogo JLine Shell (1.0.2)|1.0.2
6|Active |1|Apache Felix Gogo Runtime (1.0.2)|1.0.2
7|Active |1|snappy-java: A fast compression/decompression library
(1.1.2.6)|1.1.2.6
{noformat}
With JDK 1.8.0_131 it's fail to install the snappy bundle because of the
invalid value (win) for org.osgi.framework.os.name property
{noformat}
C:\work\felix-framework-5.6.2>..\jdk-1.8.0_131\bin\java.exe -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
C:\work\felix-framework-5.6.2>..\jdk-1.8.0_131\bin\java.exe -jar bin\felix.jar
Welcome to Apache Felix Gogo
g! context:getProperty os.name
Windows Server 2016
g! context:getProperty org.osgi.framework.os.name
win
g! install
http://central.maven.org/maven2/org/xerial/snappy/snappy-java/1.1.2.6/snappy-java-1.1.2.6.jar
Bundle ID: 7
g! start 7
org.osgi.framework.BundleException: Unable to resolve
org.xerial.snappy.snappy-java [7](R 7.0): missing requirement
[org.xerial.snappy.snappy-java [7](R 7.0)] osgi.native;
(|(&(osgi.native.osname~=win32)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=win32)(osgi.native.processor~=x64))(&(osgi.native.osname~=win32)(osgi.native.processor~=amd64))(&(osgi.native.osname~=win32)(osgi.native.processor~=x86))(&(osgi.native.osname~=macosx)(osgi.native.processor~=x86))(&(osgi.native.osname~=macosx)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x64))(&(osgi.native.osname~=linux)(osgi.native.processor~=amd64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86))(&(osgi.native.osname~=linux)(osgi.native.processor~=aarch64))(&(osgi.native.osname~=linux)(osgi.native.processor~=arm))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64le))(&(osgi.native.osname~=linux)(osgi.native.processor~=s390x))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparc)))
Unresolved requirements: [[org.xerial.snappy.snappy-java [7](R 7.0)]
osgi.native;
[jira] [Comment Edited] (FELIX-5574) When detecting an unknow Windows OS name, provides a suitable default value for org.osgi.framework.os.name
[
https://issues.apache.org/jira/browse/FELIX-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978876#comment-15978876
]
Xavier Fournet edited comment on FELIX-5574 at 4/21/17 3:00 PM:
As expected, the latest JDK8 version now recognize correctly Windows Server
2016 leading Felix to fall again in this trap.
Repro case on Windows Server 2016 + Felix 5.6.2
With JDK 1.8.0_121 it's working correctly
{noformat}
C:\work\felix-framework-5.6.2>..\jdk-1.8.0_121\bin\java.exe -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
C:\work\felix-framework-5.6.2>..\jdk-1.8.0_121\bin\java.exe -jar bin\felix.jar
Welcome to Apache Felix Gogo
g! context:getProperty os.name
Windows NT (unknown)
g! context:getProperty org.osgi.framework.os.name
windowsnt
g! install
http://central.maven.org/maven2/org/xerial/snappy/snappy-java/1.1.2.6/snappy-java-1.1.2.6.jar
Bundle ID: 7
g! start 7
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active |0|System Bundle (5.6.2)|5.6.2
1|Active |1|jansi (1.14.0)|1.14.0
2|Active |1|JLine (3.0.1)|3.0.1
3|Active |1|Apache Felix Bundle Repository (2.0.8)|2.0.8
4|Active |1|Apache Felix Gogo Command (1.0.2)|1.0.2
5|Active |1|Apache Felix Gogo JLine Shell (1.0.2)|1.0.2
6|Active |1|Apache Felix Gogo Runtime (1.0.2)|1.0.2
7|Active |1|snappy-java: A fast compression/decompression library
(1.1.2.6)|1.1.2.6
{noformat}
With JDK 1.8.0_131 it's fail to install the snappy bundle because of the
invalid value (win) for org.osgi.framework.os.name property
{noformat}
C:\work\felix-framework-5.6.2>..\jdk-1.8.0_131\bin\java.exe -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
C:\work\felix-framework-5.6.2>..\jdk-1.8.0_131\bin\java.exe -jar bin\felix.jar
Welcome to Apache Felix Gogo
g! context:getProperty os.name
Windows Server 2016
g! context:getProperty org.osgi.framework.os.name
win
g! install
http://central.maven.org/maven2/org/xerial/snappy/snappy-java/1.1.2.6/snappy-java-1.1.2.6.jar
Bundle ID: 7
g! start 7
org.osgi.framework.BundleException: Unable to resolve
org.xerial.snappy.snappy-java [7](R 7.0): missing requirement
[org.xerial.snappy.snappy-java [7](R 7.0)] osgi.native;
(|(&(osgi.native.osname~=win32)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=win32)(osgi.native.processor~=x64))(&(osgi.native.osname~=win32)(osgi.native.processor~=amd64))(&(osgi.native.osname~=win32)(osgi.native.processor~=x86))(&(osgi.native.osname~=macosx)(osgi.native.processor~=x86))(&(osgi.native.osname~=macosx)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x64))(&(osgi.native.osname~=linux)(osgi.native.processor~=amd64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86))(&(osgi.native.osname~=linux)(osgi.native.processor~=aarch64))(&(osgi.native.osname~=linux)(osgi.native.processor~=arm))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64le))(&(osgi.native.osname~=linux)(osgi.native.processor~=s390x))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparc)))
Unresolved requirements: [[org.xerial.snappy.snappy-java [7](R 7.0)]
osgi.native;
[jira] [Commented] (FELIX-5329) [Framework] Fix Java 8 packages and add Java 9 packages in default.properties
[ https://issues.apache.org/jira/browse/FELIX-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15890440#comment-15890440 ] Xavier Fournet commented on FELIX-5329: --- For thoses who are wondering the same thing, between felix 5.6.1 and 5.6.2, the list for Java 8 now contains the package org.w3c.dom.views. All packages that where in 5.6.1 are still here in 5.6.2. > [Framework] Fix Java 8 packages and add Java 9 packages in default.properties > - > > Key: FELIX-5329 > URL: https://issues.apache.org/jira/browse/FELIX-5329 > Project: Felix > Issue Type: New Feature > Components: Framework >Affects Versions: framework-5.4.0 >Reporter: Richard S. Hall >Assignee: Karl Pauls >Priority: Minor > Fix For: framework-5.6.2 > > Attachments: uses_java8.bnd > > > People are starting to experiment with Java 9, but I don't believe we've > created a Java 9 package definition yet in default.properties so that the > system bundle knows what to export. > I can't remember how we did this previously, but I think we used bnd to > analyze and come up with the packages and their "uses" constraints. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (FELIX-5574) When detecting an unknow Windows OS name, provides a suitable default value for org.osgi.framework.os.name
Xavier Fournet created FELIX-5574: - Summary: When detecting an unknow Windows OS name, provides a suitable default value for org.osgi.framework.os.name Key: FELIX-5574 URL: https://issues.apache.org/jira/browse/FELIX-5574 Project: Felix Issue Type: Improvement Components: Framework Reporter: Xavier Fournet Priority: Minor Fix For: framework-5.6.4 When the system property os.name return a Windows OS name that is not recognized by org.apache.felix.framework.util.manifestparser.NativeLibraryClause#normalizeOSName then it return "win" as a fallback value. However this "win" value is not something valid for the org.osgi.framework.os.name property name (cf https://www.osgi.org/developer/specifications/reference/) Changing the fallback value to "win32" would be better so it would allow most of the JNI library to be loaded. This would allow smooth support of future windows platform, for example for Windows Server 2016 with JDK9 (or JDK8 when https://bugs.openjdk.java.net/browse/JDK-8159948 will be fix on it) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5184) Regression: Native JNA bundle cannot be installed on Windows Server 2012
[
https://issues.apache.org/jira/browse/FELIX-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15837853#comment-15837853
]
Xavier Fournet commented on FELIX-5184:
---
The fix version is not good, since 5.6.1 release has been done the 24 October
2016, and the fix has been merged the 24 January 2017
> Regression: Native JNA bundle cannot be installed on Windows Server 2012
>
>
> Key: FELIX-5184
> URL: https://issues.apache.org/jira/browse/FELIX-5184
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.4.0
> Environment: Windows 2012
>Reporter: Stuart McCulloch
>Assignee: David Bosschaert
> Fix For: framework-5.6.1
>
>
> The alias for Windows 2012 seems to have been lost when the "osname" aliases
> were moved to framework/src/main/resources/default.properties (in
> https://github.com/apache/felix/commit/c2b87c099bf3b5efc535cc80abc0d78fe9a7c2c0)
> The following line should be added to
> framework/src/main/resources/default.properties:
> {code}
> felix.native.osname.alias.windowsserver2012=windows server 2012,win32
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5143) Gogo Command bundle should not include org.osgi.service.log classes
Xavier Fournet created FELIX-5143: - Summary: Gogo Command bundle should not include org.osgi.service.log classes Key: FELIX-5143 URL: https://issues.apache.org/jira/browse/FELIX-5143 Project: Felix Issue Type: Bug Components: Gogo Command Reporter: Xavier Fournet Fix For: gogo.command-0.18.0 The classes of org.osgi.service.log are present in the Gogo command jar files. The bundle should instead import this package. It seems that there was a confusion between Export-Package and Import-Package in the BND directives in pom.xml -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5140) Update Jetty to version 9.2.14
Xavier Fournet created FELIX-5140: - Summary: Update Jetty to version 9.2.14 Key: FELIX-5140 URL: https://issues.apache.org/jira/browse/FELIX-5140 Project: Felix Issue Type: Improvement Reporter: Xavier Fournet Priority: Minor Version 9.2.14 is out since one month -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5117) Call to SSOHttpSessionListener#sessionDestroyed is done after the session is invalidated
Xavier Fournet created FELIX-5117:
-
Summary: Call to SSOHttpSessionListener#sessionDestroyed is done
after the session is invalidated
Key: FELIX-5117
URL: https://issues.apache.org/jira/browse/FELIX-5117
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http.jetty-3.1.2, http.jetty-3.1.0, http.base-3.0.2,
http.base-3.0.0
Reporter: Xavier Fournet
The javadoc of javax.servlet.http.HttpSessionListener#sessionDestroyed indicate
that the method should called before the session is invalidated ("Receives
notification that a session is about to be invalidated.").
This was working correctly with HTTP Felix 2.x but no more working with HTTP
Felix 3.1.x because the method is called after the session is invalidated, so
any attempt to get information from the session in this method will throw an
exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5110) HTTP resources content type are not set when using whiteboard pattern
Xavier Fournet created FELIX-5110: - Summary: HTTP resources content type are not set when using whiteboard pattern Key: FELIX-5110 URL: https://issues.apache.org/jira/browse/FELIX-5110 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http.jetty-3.1.2, http.jetty-3.1.0 Reporter: Xavier Fournet As written in the javadoc of org.osgi.service.http.context.ServletContextHelper#getMimeType, when it return null "the Http Whiteboard implementation should determine the MIME type itself" When registering resource through the HTTP service, a similar default mecanism is working well. But the whiteboard pattern, no content type is determined at all. This cause problem (eg serving .css with no content type is not accepted by IE) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5093) HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
[
https://issues.apache.org/jira/browse/FELIX-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014660#comment-15014660
]
Xavier Fournet commented on FELIX-5093:
---
Ok i see, i missed the execution of felix.http.itests. I will look at the
result of thoses tests.
> HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
> --
>
> Key: FELIX-5093
> URL: https://issues.apache.org/jira/browse/FELIX-5093
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.1.0, http.jetty-3.1.2
>Reporter: Xavier Fournet
>Assignee: Carsten Ziegeler
>Priority: Blocker
> Fix For: http.jetty-3.1.4
>
> Attachments: requesturibug-1.0.0-SNAPSHOT.jar,
> requesturibug-sources.zip
>
>
> The HttpServletRequest.getRequestURI must return the URI without processing %
> escaping. Since version 3.1.0 this processing is done, so the returned value
> is incorrect. For exemple this can lead to error in Apache Shiro when it try
> to unescape % of an URI.
> See the attached jar for a bundle that can be used to reproduce the problem:
> * load the bundle
> * with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
> With HTTP Jetty < 3.1.0 it prints:
> {noformat}
> Request URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is ok
> With HTTP Jetty 3.1.0 or 3.1.2 it prints:
> {noformat}
> Request URI: /requesturibug/test/test%test
> (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is wrong while the underlying request URI returned by Jetty
> itself is correct.
> When this request come the Shiro filter it will issue an exception because it
> will try to unescape "%te" which is not valid since "te" is not a number
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5093) HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
[
https://issues.apache.org/jira/browse/FELIX-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14994519#comment-14994519
]
Xavier Fournet commented on FELIX-5093:
---
Fix proposition : https://github.com/apache/felix/pull/39
> HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
> --
>
> Key: FELIX-5093
> URL: https://issues.apache.org/jira/browse/FELIX-5093
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.1.0, http.jetty-3.1.2
>Reporter: Xavier Fournet
>Priority: Blocker
> Fix For: http.jetty-3.1.4
>
> Attachments: requesturibug-1.0.0-SNAPSHOT.jar,
> requesturibug-sources.zip
>
>
> The HttpServletRequest.getRequestURI must return the URI without processing %
> escaping. Since version 3.1.0 this processing is done, so the returned value
> is incorrect. For exemple this can lead to error in Apache Shiro when it try
> to unescape % of an URI.
> See the attached jar for a bundle that can be used to reproduce the problem:
> * load the bundle
> * with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
> With HTTP Jetty < 3.1.0 it prints:
> {noformat}
> Request URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is ok
> With HTTP Jetty 3.1.0 or 3.1.2 it prints:
> {noformat}
> Request URI: /requesturibug/test/test%test
> (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is wrong while the underlying request URI returned by Jetty
> itself is correct.
> When this request come the Shiro filter it will issue an exception because it
> will try to unescape "%te" which is not valid since "te" is not a number
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (FELIX-5093) HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
[
https://issues.apache.org/jira/browse/FELIX-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Fournet updated FELIX-5093:
--
Comment: was deleted
(was: Fix proposition : https://github.com/apache/felix/pull/39)
> HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
> --
>
> Key: FELIX-5093
> URL: https://issues.apache.org/jira/browse/FELIX-5093
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.1.0, http.jetty-3.1.2
>Reporter: Xavier Fournet
>Priority: Blocker
> Fix For: http.jetty-3.1.4
>
> Attachments: requesturibug-1.0.0-SNAPSHOT.jar,
> requesturibug-sources.zip
>
>
> The HttpServletRequest.getRequestURI must return the URI without processing %
> escaping. Since version 3.1.0 this processing is done, so the returned value
> is incorrect. For exemple this can lead to error in Apache Shiro when it try
> to unescape % of an URI.
> See the attached jar for a bundle that can be used to reproduce the problem:
> * load the bundle
> * with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
> With HTTP Jetty < 3.1.0 it prints:
> {noformat}
> Request URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is ok
> With HTTP Jetty 3.1.0 or 3.1.2 it prints:
> {noformat}
> Request URI: /requesturibug/test/test%test
> (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is wrong while the underlying request URI returned by Jetty
> itself is correct.
> When this request come the Shiro filter it will issue an exception because it
> will try to unescape "%te" which is not valid since "te" is not a number
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5093) HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
[
https://issues.apache.org/jira/browse/FELIX-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Fournet updated FELIX-5093:
--
Attachment: requesturibug-1.0.0-SNAPSHOT.jar
> HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
> --
>
> Key: FELIX-5093
> URL: https://issues.apache.org/jira/browse/FELIX-5093
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.1.0, http.jetty-3.1.2
>Reporter: Xavier Fournet
>Priority: Blocker
> Attachments: requesturibug-1.0.0-SNAPSHOT.jar
>
>
> The HttpServletRequest.getRequestURI must return the URI without processing %
> escaping. Since version 3.1.0 this processing is done, so the returned value
> is incorrect. For exemple this can lead to error in Apache Shiro when it try
> to unescape % of an URI.
> See the attached jar for a bundle that can be used to reproduce the problem:
> * load the bundle
> * with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
> With HTTP Jetty < 3.1.0 it prints:
> {noformat}
> Request URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is ok
> With HTTP Jetty 3.1.0 or 3.1.2 it prints:
> {noformat}
> Request URI: /requesturibug/test/test%test
> (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is wrong while the underlying request URI returned by Jetty
> itself is correct
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5093) HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
[
https://issues.apache.org/jira/browse/FELIX-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Fournet updated FELIX-5093:
--
Description:
The HttpServletRequest.getRequestURI must return the URI without processing %
escaping. Since version 3.1.0 this processing is done, so the returned value is
incorrect. For exemple this can lead to error in Apache Shiro when it try to
unescape % of an URI.
See the attached jar for a bundle that can be used to reproduce the problem:
* load the bundle
* with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
With HTTP Jetty < 3.1.0 it prints:
{noformat}
Request URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is ok
With HTTP Jetty 3.1.0 or 3.1.2 it prints:
{noformat}
Request URI: /requesturibug/test/test%test
(org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is wrong while the underlying request URI returned by Jetty
itself is correct
was:
The HttpServletRequest.getRequestURI must return the URI without processing %
escaping. Since version 3.1.0 this processing is done, so the returned value is
incorrect. For exemple this can lead to error in Apache Shiro when it try to
unescape % of an URI.
See the attached jar for a bundle that can be used to reproduce the problem:
* load the bundle
* with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
With HTTP Jetty < 3.0.0 it prints:
{noformat}
Request URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is ok
With HTTP Jetty 3.1.0 or 3.1.2 it prints:
{noformat}
Request URI: /requesturibug/test/test%test
(org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is wrong while the underlying request URI returned by Jetty
itself is correct
> HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
> --
>
> Key: FELIX-5093
> URL: https://issues.apache.org/jira/browse/FELIX-5093
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.1.0, http.jetty-3.1.2
>Reporter: Xavier Fournet
>Priority: Blocker
>
> The HttpServletRequest.getRequestURI must return the URI without processing %
> escaping. Since version 3.1.0 this processing is done, so the returned value
> is incorrect. For exemple this can lead to error in Apache Shiro when it try
> to unescape % of an URI.
> See the attached jar for a bundle that can be used to reproduce the problem:
> * load the bundle
> * with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
> With HTTP Jetty < 3.1.0 it prints:
> {noformat}
> Request URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is ok
> With HTTP Jetty 3.1.0 or 3.1.2 it prints:
> {noformat}
> Request URI: /requesturibug/test/test%test
> (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is wrong while the underlying request URI returned by Jetty
> itself is correct
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5093) HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
[
https://issues.apache.org/jira/browse/FELIX-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Fournet updated FELIX-5093:
--
Description:
The HttpServletRequest.getRequestURI must return the URI without processing %
escaping. Since version 3.1.0 this processing is done, so the returned value is
incorrect. For exemple this can lead to error in Apache Shiro when it try to
unescape % of an URI.
See the attached jar for a bundle that can be used to reproduce the problem:
* load the bundle
* with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
With HTTP Jetty < 3.1.0 it prints:
{noformat}
Request URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is ok
With HTTP Jetty 3.1.0 or 3.1.2 it prints:
{noformat}
Request URI: /requesturibug/test/test%test
(org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is wrong while the underlying request URI returned by Jetty
itself is correct.
When this request come the Shiro filter it will issue an exception because it
will try to unescape "%te" which is not valid since "te" is not a number
was:
The HttpServletRequest.getRequestURI must return the URI without processing %
escaping. Since version 3.1.0 this processing is done, so the returned value is
incorrect. For exemple this can lead to error in Apache Shiro when it try to
unescape % of an URI.
See the attached jar for a bundle that can be used to reproduce the problem:
* load the bundle
* with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
With HTTP Jetty < 3.1.0 it prints:
{noformat}
Request URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is ok
With HTTP Jetty 3.1.0 or 3.1.2 it prints:
{noformat}
Request URI: /requesturibug/test/test%test
(org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is wrong while the underlying request URI returned by Jetty
itself is correct
> HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
> --
>
> Key: FELIX-5093
> URL: https://issues.apache.org/jira/browse/FELIX-5093
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.1.0, http.jetty-3.1.2
>Reporter: Xavier Fournet
>Priority: Blocker
> Attachments: requesturibug-1.0.0-SNAPSHOT.jar,
> requesturibug-sources.zip
>
>
> The HttpServletRequest.getRequestURI must return the URI without processing %
> escaping. Since version 3.1.0 this processing is done, so the returned value
> is incorrect. For exemple this can lead to error in Apache Shiro when it try
> to unescape % of an URI.
> See the attached jar for a bundle that can be used to reproduce the problem:
> * load the bundle
> * with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
> With HTTP Jetty < 3.1.0 it prints:
> {noformat}
> Request URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is ok
> With HTTP Jetty 3.1.0 or 3.1.2 it prints:
> {noformat}
> Request URI: /requesturibug/test/test%test
> (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is wrong while the underlying request URI returned by Jetty
> itself is correct.
> When
[jira] [Updated] (FELIX-5093) HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
[
https://issues.apache.org/jira/browse/FELIX-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Fournet updated FELIX-5093:
--
Description:
The HttpServletRequest.getRequestURI must return the URI without processing %
escaping. Since version 3.1.0 this processing is done, so the returned value is
incorrect. For exemple this can lead to error in Apache Shiro when it try to
unescape % of an URI.
See the attached jar for a bundle that can be used to reproduce the problem:
* load the bundle
* with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
With HTTP Jetty < 3.0.0 it prints:
{noformat}
Request URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is ok
With HTTP Jetty 3.1.0 or 3.1.2 it prints:
{noformat}
Request URI: /requesturibug/test/test%test
(org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is wrong while the underlying request URI returned by Jetty
itself is correct
was:
The HttpServletRequest.getRequestURI must return the URI without processing %
escaping. Since version 3.1.0 this processing is done, so the returned value is
incorrect. For exemple this can lead to error in Apache Shiro when it try to
unescape % of an URI.
See the attached jar for a bundle that can be used to reproduce the problem:
* load the bundle
* with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
With HTTP Jetty < 3.0.0 it prints:
{noformat}
Request URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is ok
With HTTP Jetty 3.0.0 or 3.0.2 it prints:
{noformat}
Request URI: /requesturibug/test/test%test
(org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
Wrapped URI: /requesturibug/test%2Ftest%25test
(org.eclipse.jetty.server.Request)
{noformat}
=> request URI is wrong while the underlying request URI returned by Jetty
itself is correct
> HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
> --
>
> Key: FELIX-5093
> URL: https://issues.apache.org/jira/browse/FELIX-5093
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.1.0, http.jetty-3.1.2
>Reporter: Xavier Fournet
>Priority: Blocker
>
> The HttpServletRequest.getRequestURI must return the URI without processing %
> escaping. Since version 3.1.0 this processing is done, so the returned value
> is incorrect. For exemple this can lead to error in Apache Shiro when it try
> to unescape % of an URI.
> See the attached jar for a bundle that can be used to reproduce the problem:
> * load the bundle
> * with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
> With HTTP Jetty < 3.0.0 it prints:
> {noformat}
> Request URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is ok
> With HTTP Jetty 3.1.0 or 3.1.2 it prints:
> {noformat}
> Request URI: /requesturibug/test/test%test
> (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is wrong while the underlying request URI returned by Jetty
> itself is correct
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5093) HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
[
https://issues.apache.org/jira/browse/FELIX-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Fournet updated FELIX-5093:
--
Attachment: requesturibug-sources.zip
> HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
> --
>
> Key: FELIX-5093
> URL: https://issues.apache.org/jira/browse/FELIX-5093
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.1.0, http.jetty-3.1.2
>Reporter: Xavier Fournet
>Priority: Blocker
> Attachments: requesturibug-1.0.0-SNAPSHOT.jar,
> requesturibug-sources.zip
>
>
> The HttpServletRequest.getRequestURI must return the URI without processing %
> escaping. Since version 3.1.0 this processing is done, so the returned value
> is incorrect. For exemple this can lead to error in Apache Shiro when it try
> to unescape % of an URI.
> See the attached jar for a bundle that can be used to reproduce the problem:
> * load the bundle
> * with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
> With HTTP Jetty < 3.1.0 it prints:
> {noformat}
> Request URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is ok
> With HTTP Jetty 3.1.0 or 3.1.2 it prints:
> {noformat}
> Request URI: /requesturibug/test/test%test
> (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is wrong while the underlying request URI returned by Jetty
> itself is correct
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5093) HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
[
https://issues.apache.org/jira/browse/FELIX-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986283#comment-14986283
]
Xavier Fournet commented on FELIX-5093:
---
The regression has been introduced by FELIX-4925
> HttpServletRequest.getRequestURI is broken for escaped char in URL since 3.1.0
> --
>
> Key: FELIX-5093
> URL: https://issues.apache.org/jira/browse/FELIX-5093
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.jetty-3.1.0, http.jetty-3.1.2
>Reporter: Xavier Fournet
>Priority: Blocker
> Attachments: requesturibug-1.0.0-SNAPSHOT.jar,
> requesturibug-sources.zip
>
>
> The HttpServletRequest.getRequestURI must return the URI without processing %
> escaping. Since version 3.1.0 this processing is done, so the returned value
> is incorrect. For exemple this can lead to error in Apache Shiro when it try
> to unescape % of an URI.
> See the attached jar for a bundle that can be used to reproduce the problem:
> * load the bundle
> * with a browser go on http://localhost:8080/requesturibug/test%2Ftest%25test
> With HTTP Jetty < 3.1.0 it prints:
> {noformat}
> Request URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.handler.ServletHandlerRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.dispatch.FilterPipeline$FilterRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.apache.felix.http.base.internal.DispatcherServlet$AttributeEventRequest)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is ok
> With HTTP Jetty 3.1.0 or 3.1.2 it prints:
> {noformat}
> Request URI: /requesturibug/test/test%test
> (org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper)
> Wrapped URI: /requesturibug/test%2Ftest%25test
> (org.eclipse.jetty.server.Request)
> {noformat}
> => request URI is wrong while the underlying request URI returned by Jetty
> itself is correct.
> When this request come the Shiro filter it will issue an exception because it
> will try to unescape "%te" which is not valid since "te" is not a number
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
