we are developing an application in Vaadin and are running into problems with special character in uri fragments in Vaadin 7.1.0. We are dealing with search strings, that needs to be bookmarked, so that we are creating Uri fragments containing these search strings. Fortunately, almost every special character is handled by Vaadin. Unfortunately, there are two exceptions: the hash-sign (#) and the plus-sign (+). In order to investigate the odd behaviour our application has, i’ve created a sample application using the project creation wizard of Vaadin. In the init method of the UI derived class, i added the UI class as an UriFragmentChangedListener and implemented the necessary interface. Now i run the application under tomcat and entered the following URL’s:
The application directly run into a “java.lang.RuntimeException: java.net.URISyntaxException: Illegal character in fragment at index 47: http://localhost:8080/UriFragmentBugTest/#test=#” exception. The UriFragmentChangedEvent isn’t even fired. Is this a bug? What am i doing wrong? The application becomes useless, because a big tooltip containing the exception is following the mouse cursor. How can i prevent the application to become useless? Is there a way to use the hash sign in uri fragments?
With this Url, the UriFragmentChangedEvent is fired, but the url in the event data is missing the plus sign. The plus sign seems to be replaced by a space character. Is there a way to use the plus sign in uri fragments?
The exception comes from java.net.URI parsing. I’m not sure where the parsing is triggered, but according to RFC3986, unescaped hash signs are not allowed within the fragment (see e.g.
this thread .
The mapping of “+” to space might take place in the browser, in the server or in Vaadin - I’m not sure where it is done. Technically, a plus sign should be allowed within the fragment so if Vaadin is unescaping it into a space in the fragment, please
create a ticket about it.
The lack of encoding the hash character seems to be actually a bug in GWT. In c.g.gwt.http.client.UrlBuilder the following is done:
url.append("#").append(URL.encode(hash));
The URL.encode() method does
not escape the hash or other URL component separator characters. URL.encodePathSegment() should probably be used instead.
I frequently have this with clients coming from google search:
(Vaadin 7.7.1)
Sep 19, 2016 4:08:04 AM org.apache.catalina.core.StandardWrapperValve invoke
SCHWERWIEGEND: Servlet.service() for servlet [net.vidjay.vjapp.VjappUI$Servlet]
in context with path
[/vjapp] threw exception [com.vaadin.server.ServiceException: java.lang.RuntimeException: Invalid location URI received from client]
with root cause
java.net.URISyntaxException: Illegal character in path at index 24: http://vidjay.net/es/Lil Wayne, Wiz Khalifa & Imagine Dragons w Logic & Ty $ign
at java.net.URI$Parser.fail(URI.java:2848)
at java.net.URI$Parser.checkChars(URI.java:3021)
at java.net.URI$Parser.parseHierarchical(URI.java:3105)
at java.net.URI$Parser.parse(URI.java:3053)
at java.net.URI.(URI.java:588)
at com.vaadin.server.Page.init(Page.java:651)
at com.vaadin.ui.UI.doInit(UI.java:684)
at com.vaadin.server.communication.UIInitHandler.getBrowserDetailsUI(UIInitHandler.java:214)
at com.vaadin.server.communication.UIInitHandler.synchronizedHandleRequest(UIInitHandler.java:74)
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:41)
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1414)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:365)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1081)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)