Re: + character is always encoded in url path after request dispatch since #59317
On 24/04/17 15:57, Tobias Brennecke wrote: > On 24/04/17 14:24, Mark Thomas wrote: > >> >>> That looks like a bug to me. >>> >>> We need to go through and check all the places URLs are being encoding >>> and check it is being done correctly. >> This is now complete for 9.0.x, 8.5.x, 8.0.x and 7.0.x. >> >>> I am concerned that fixing this may break apps that rely on the broken >>> behaviour. We might need to provide some configuration to work around this. >> I haven't provided any configuration options yet. Any issues will be >> considered on a case by case basis. >> >> Mark > > Hi Mark, > > thanks a lot for looking into this! I already saw you added this to the > (unreleased) changelog. > Just let me know if you could use some help, if there's still anything > to do? > Maybe with a patch or by improving unit tests and documentation? Hi Tobias, The Tomcat community always welcomes additional help. Additional unit tests are always would be welcome. Generally, a new unit test should aim to improve (however slightly) the code code coverage [1]. In terms of where to start looking, URLEncoder is pretty well covered. It looks like it is the error cases that need testing. In terms of the other functionality, the test I had to fix after applying this patch [2] might give you some ideas. If there are areas of documentation you think could be improved then patches for those changes would also be very welcome. Equally, please take the above as suggestions rather than as an instruction. Anywhere you'd like to start contributing would be great. Kind regards, Mark [1] https://ci.apache.org/projects/tomcat/tomcat9/coverage/ [2] http://svn.apache.org/viewvc?rev=1792468&view=rev > > > > Many regards, > > Tobias > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: + character is always encoded in url path after request dispatch since #59317
On 24/04/17 14:24, Mark Thomas wrote: > >> That looks like a bug to me. >> >> We need to go through and check all the places URLs are being encoding >> and check it is being done correctly. > This is now complete for 9.0.x, 8.5.x, 8.0.x and 7.0.x. > >> I am concerned that fixing this may break apps that rely on the broken >> behaviour. We might need to provide some configuration to work around this. > I haven't provided any configuration options yet. Any issues will be > considered on a case by case basis. > > Mark Hi Mark, thanks a lot for looking into this! I already saw you added this to the (unreleased) changelog. Just let me know if you could use some help, if there's still anything to do? Maybe with a patch or by improving unit tests and documentation? Many regards, Tobias - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: + character is always encoded in url path after request dispatch since #59317
Thanks for providing the information & confirm me what are all the details required from my end. Many times we are facing the same issues with the same revision tomcat setup only, PFA e-mail for your ref: Regards, Naga Ramesh R 9972229728 -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, April 24, 2017 5:54 PM To: Tomcat Users List Subject: Re: + character is always encoded in url path after request dispatch since #59317 On 21/04/17 20:54, Mark Thomas wrote: > On 21/04/17 17:27, Tobias Brennecke wrote: > > > >> My question is whether this behavior is intended or if this is a bug. > > That looks like a bug to me. > > We need to go through and check all the places URLs are being encoding > and check it is being done correctly. This is now complete for 9.0.x, 8.5.x, 8.0.x and 7.0.x. > I am concerned that fixing this may break apps that rely on the broken > behaviour. We might need to provide some configuration to work around this. I haven't provided any configuration options yet. Any issues will be considered on a case by case basis. Mark > >> As I'm a native German speaker, I apologize for any grammar mistakes >> or misspellings. Thank you for your efforts and patience while >> reading this mail. > > No need to apologise. I had no idea you weren't a native English > speaker (I am) until I read that last sentence. > > Kind regards, > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --- Begin Message --- Tomcat Team, Always we are getting the below mentioned errors, please check ASAP and guide me if anything missing from our end, this is very urgent, please respond asap. Tomcat Version: apache-tomcat-8.0.33 Java Version: "1.8.0_77" Setenv.sh file setting: export JAVA_OPTS="$JAVA_OPTS -DR_E_T_A_P_P" export CATALINA_OPTS="$CATALINA_OPTS -Xms1024m" export CATALINA_OPTS="$CATALINA_OPTS -Xmx4196m" #export CATALINA_OPTS="$CATALINA_OPTS -Xss64m" export CATALINA_OPTS="$CATALINA_OPTS -server" export CATALINA_OPTS="$CATALINA_OPTS -XX:+TieredCompilation -XX:+AggressiveOpts -XX:+UseG1GC -XX:SurvivorRatio=1 -XX:NewRatio=2 -XX:MaxTenuringThreshold=15 -XX:-UseAda ptiveSizePolicy -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=512m -XX:-UseSplitVerifier -noverify" export LD_LIBRARY_PATH=/usr/lib64/ Errors: 24-Apr-2017 12:16:18.701 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service Catalina 24-Apr-2017 12:16:18.701 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: rafg 24-Apr-2017 12:16:18.707 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /opt/install/ra6.6/apache-tomcat-8.0.33/webapps/ROOT 24-Apr-2017 12:16:31.198 SEVERE [localhost-startStop-1] org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:153) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:7 25) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1092) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1 834) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11 42) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6 17) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalStateException: Unable to complete the scan for annotations for web application [] due to a StackOverflowError. Possible root causes include a too low setting for -Xss and illegal cyclic inheritance dependencies. The class hierarchy being processed was [org.bouncycastle.asn1.ASN1EncodableVector->org.bouncycastle.asn1.DEREncodab leVector->org.bouncycastle.asn1.ASN1EncodableVector] at org.apac
Re: + character is always encoded in url path after request dispatch since #59317
On 21/04/17 20:54, Mark Thomas wrote: > On 21/04/17 17:27, Tobias Brennecke wrote: > > > >> My question is whether this behavior is intended or if this is a bug. > > That looks like a bug to me. > > We need to go through and check all the places URLs are being encoding > and check it is being done correctly. This is now complete for 9.0.x, 8.5.x, 8.0.x and 7.0.x. > I am concerned that fixing this may break apps that rely on the broken > behaviour. We might need to provide some configuration to work around this. I haven't provided any configuration options yet. Any issues will be considered on a case by case basis. Mark > >> As I'm a native German speaker, I apologize for any grammar mistakes or >> misspellings. Thank you for your efforts and patience while reading this >> mail. > > No need to apologise. I had no idea you weren't a native English speaker > (I am) until I read that last sentence. > > Kind regards, > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: + character is always encoded in url path after request dispatch since #59317
On 21/04/17 17:27, Tobias Brennecke wrote: > My question is whether this behavior is intended or if this is a bug. That looks like a bug to me. We need to go through and check all the places URLs are being encoding and check it is being done correctly. I am concerned that fixing this may break apps that rely on the broken behaviour. We might need to provide some configuration to work around this. > As I'm a native German speaker, I apologize for any grammar mistakes or > misspellings. Thank you for your efforts and patience while reading this > mail. No need to apologise. I had no idea you weren't a native English speaker (I am) until I read that last sentence. Kind regards, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
