Invalid-URI-Exception

[thir...@gmx.net]

Just ran into this error below.

Figured out it's because of the sqare brackets, which indeed would be invalid.

The server then degrades rapidly when many succh requests are made, while the client waits forever, which seems like a bit too much of a punishment ;)

Do I have to validate incoming requests beforehand to be able to respond with an error instead?

java.lang.IllegalArgumentException: Invalid uri <some uri with square brackets [] in it>

        at org.vertx.java.core.http.impl.DefaultHttpServerRequest.juri(DefaultHttpServerRequest.java:341)

        at org.vertx.java.core.http.impl.DefaultHttpServerRequest.path(DefaultHttpServerRequest.java:127)

        at org.vertx.java.core.http.RouteMatcher.route(RouteMatcher.java:340)

        at org.vertx.java.core.http.RouteMatcher.handle(RouteMatcher.java:59)

        at org.vertx.groovy.core.http.RouteMatcher$_asClosure_closure1.doCall(RouteMatcher.groovy:283)

        at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:601)

        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)

        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)

        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)

        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)

        at groovy.lang.Closure.call(Closure.java:411)

        at groovy.lang.Closure.call(Closure.java:427)

        at org.vertx.groovy.core.http.impl.DefaultHttpServer$_requestHandler_closure2.doCall(DefaultHttpServer.groovy:48)

        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:601)

        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)

        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)

        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)

        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)

        at groovy.lang.Closure.call(Closure.java:411)

        at org.codehaus.groovy.runtime.ConvertedClosure.invokeCustom(ConvertedClosure.java:51)

        at org.codehaus.groovy.runtime.ConversionHandler.invoke(ConversionHandler.java:81)

        at com.sun.proxy.$Proxy7.handle(Unknown Source)

        at org.vertx.java.core.http.impl.ServerConnection.handleRequest(ServerConnection.java:180)

        at org.vertx.java.core.http.impl.ServerConnection.processMessage(ServerConnection.java:290)

        at org.vertx.java.core.http.impl.ServerConnection.handleMessage(ServerConnection.java:95)

        at org.vertx.java.core.http.impl.DefaultHttpServer$ServerHandler.doMessageReceived(DefaultHttpServer.java:612)

        at org.vertx.java.core.http.impl.DefaultHttpServer$ServerHandler.doMessageReceived(DefaultHttpServer.java:542)

        at org.vertx.java.core.http.impl.VertxHttpHandler$1.run(VertxHttpHandler.java:111)

        at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:171)

        at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:171)

        at org.vertx.java.core.impl.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:90)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

        at java.lang.Thread.run(Thread.java:722)

[Norman Maurer]

I guess the slow down you are seeing is because all of the fillStrackTrace() that are performed and are expensive.

I'm currently wonder if we may need to write a more "relaxed" URI parser to eliminate such issues. Let me think about it.

Bye,

Norman

Ps: If you could supply the uri that caused this issues it would really help.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[petermd]

I'd assume the slowdown is because if an exception is thrown in the Handler vert.x doesn't reply to the Http request (keeping the connection open until the client times out)? On a busy system this will quickly degrade performance.

-peter

[thir...@gmx.net]

Just request any URI that contains "]" or "[" in its path, in my case it was  e.g. http://localhost:8080/reports/20130722-013117/charts/requests/BrowserShutdown%20[lpt]%20[order-system]%20$2fbasket$2famount%20[HTML].png . The filenames result from some configuration elsewhere so are hardly restrictable... The escaping is obviously done by the browser. Once I removed the last square bracket in this case, it worked. Every URI with a (single) square bracket will produce this behaviour. However any square brackets would indeed be invalid, see here http://stackoverflow.com/questions/40568/square-brackets-in-urls.

[thir...@gmx.net]

Apache does serve those files however.

[Norman Maurer]

Could please retry with latest code from master ? I just pushed a change which will use some kind of "relaxed" parsing for path() and query().

The same strict parsing is used for absoluteURI() as before as there is no way to get around this.

Bye,

Norman

[thir...@gmx.net]

Hi Norman, 

I just tried it with latest from master. When on first try it didn't work, I was quickly to add decoding of the URI and it worked!

Now it seems to me, that it would always make sense to to this, since, afaik the java.net.URLDecoder wouldn't decode "overeagerly", unlike e.g. http://meyerweb.com/eric/tools/dencoder/

This is the handler I ended up with:

rm.getWithRegEx(/\/reports\/\d{8}-\d{6}.*/) { request ->

logDebug("Received request ${request.method} ${request.uri}")

def root = reportDir.rootDir.path - (File.separator + "reports")

def path = root + request.uri

path = URLDecoder.decode(path, "UTF-8")

if(new File(path).isFile()) {

request.response.sendFile(path)

} else {

request.response.end("Ressource not found")

}

}

On a sidenote, what would be a good way get around the if(new File(path).isFile()) ? Since the client would also wait forever if i tried to serve a directory... 

I'm asking myself whether a simple directory browser like Apache has would be something implemented in either a webserver-module or even core in form of a sendDirectory()-method.

But my main interest would be robustness anways!

Much appreciation for your project!

Bye, 

Thomas

[Norman Maurer]

Sorry I'm confused,

what you mean with "at first it didn't work" ? Did it throw an exception again ?

Bye,

Norman

[thir...@gmx.net]

Sorry, what I meant was with only pulling vert.x-master and restarting the app, it did not throw any Exceptions (so your change did solve the problem with the hanging server). 

Everything's fine from the exception point of view!

But the files did not get served because of the URL-escaping. 

So I had to unescape the URI with URLDecoder.decode().

That's why I pasted that method as an example.

Now that seems to me like such a generic step, I would almost expect it to be done by vert.x implicitly.

Would that make any sense?

With the method I pasted, everything works as expected. I'm just asking the question, would it not be a good idea to *always* decode any URI before passing it to sendFile(), just to be prepared for the case where that file/URI contains any escaped characters like space and whatnot.

On the other hand, that would probably cause problems when serving files that actually do have escaped characters in their names, e.g. "my%20file.csv".

so there might be no generic solution to this problem, or I might be thinking too complicated here.

Anyways, thanks for your time!