Problems with # and + in uri fragments


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:

  1. Url: http://localhost:8080/UriFragmentBugTest/#test=#

The application directly run into a “java.lang.RuntimeException: 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?

  1. Url: http://localhost:8080/UriFragmentBugTest/#test=‘+’

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?

Thanks in advance.

Volker Goehrke.

Same problem. Did you solve this?

Best practice would be to URLEncode the value of every parameter & parametername

should be

When you read the Paramater value , decode it again.

  1. The exception comes from 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

  2. 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
escape the hash or other URL component separator characters. URL.encodePathSegment() should probably be used instead.

Opened Vaadin
ticket 12796
and GWT
issue 8396

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 Illegal character in path at index 24: Wayne, Wiz Khalifa & Imagine Dragons w Logic & Ty $ign
at com.vaadin.server.Page.init(
at com.vaadin.ui.UI.doInit(
at com.vaadin.server.communication.UIInitHandler.getBrowserDetailsUI(
at com.vaadin.server.communication.UIInitHandler.synchronizedHandleRequest(
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(
at com.vaadin.server.VaadinService.handleRequest(
at com.vaadin.server.VaadinServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.tomcat.websocket.server.WsFilter.doFilter(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.valves.ErrorReportValve.invoke(
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(
at org.apache.catalina.core.StandardEngineValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.service(
at org.apache.coyote.http11.AbstractHttp11Processor.process(
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$
at org.apache.tomcat.util.threads.TaskThread$