Lagom: URI encoded slahes in path parameters lead to action not found

[domkun]

Lagom Version (1.2.x / 1.3.x / etc)

1.3.5 Dev Mode

API (Scala / Java / Neither / Both)

Java

Operating System (Ubuntu 15.10 / MacOS 10.10 / Windows 10)

4.4.0-77-generic #98-Ubuntu SMP Wed Apr 26 08:34:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

JDK

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)

Expected Behavior

When sending requests to the hello endpoint of the from archetype generated project, defined as pathCall("/api/hello/:id", this::hello), and the id parameter contains URI encoded slashes (http://localhost:9000/api/hello/Alice%2FThat%2Fis%2Fmy%2Fname), it should invoke the service method with the id provided.

Actual Behavior

A 404 - Action not found page is rendered. Stating that all routes have been tried but none is matching.

<h1>Action Not Found</h1>

        <p id="detail">
            For request 'GET /api/hello/Alice/That/is/my/name'
        </p>
...

[domkun]

I did some research and it seems that most applications do not support this per default. Apache Tomcat and httpd both have extra settings to enable this.

So this seems only relevant for the dev mode as in a production environment the gateway is some technology outside the scope of Lagom (if I am correct?).

In Lagom the ServiceGateway uses the Java URI.create method which does the decoding of the %2F triplets automatically. (see https://github.com/lagom/lagom/blob/master/dev/service-registry/service-locator/src/main/scala/com/lightbend/lagom/gateway/ServiceGateway.scala#L113). So the only solution that comes into my mind is to build a custom URI decoder.

This however seems a bit of an overkill to me and will not provide that much benefit given that for production deployments this has to be considered differently.

From my opinion this may be closed. Sorry for that, next time I will do the deep research upfront.

[octonato]

Not sure if that's is overkill. If it's a valid use case for production, we should provide the option in dev mode as well.

This could eventually be achieved with a configuration option like 'gateway.decode.request.url' defaulting to 'true'.

[domkun]

This is not an easy change, I think this also affects the ServiceRouter.scala (https://github.com/lagom/lagom/blob/master/service/core/server/src/main/scala/com/lightbend/lagom/internal/server/ServiceRouter.scala#L212)

I have found a discussion about this in the Play Framework repository, see https://github.com/playframework/playframework/issues/937

I don't think I am able to provide much assistance here, I am too new to Lagom, Scala, Play, ...

[richdougherty]

I've tested this in Play and if we call a route like

GET     /api/hello/:id              controllers.HomeController.printString(id: String)

with http://localhost:9000/api/hello/Alice%2FThat%2Fis%2Fmy%2Fname we get an id of Alice/That/is/my/name. I.e. the path segment Alice%2FThat%2Fis%2Fmy%2Fname is correctly unescaped and passed as the id parameter.

But I suppose Lagom doesn't use a standard routes file. How does Lagom call the Play APIs when routing a call? Does it use the _sird_ API?

[richdougherty]

A question for you, @domkun:

it should invoke the service method with the id provided.

Does this mean that you expect an id of Alice%2FThat%2Fis%2Fmy%2Fname or an id of Alice/That/is/my/name? I'd expect the latter, but I want to clarify what you're expecting. :)

[domkun]

Sorry for the delay. Yes, I expected Alice/That/is/my/name

[richdougherty]

OK thanks for confirming that. That behaviour is what we're getting when using a standard Play router. Lagom is probably using a different technique for routing.

[TimMoore]

Just did a bit more testing:

• When hitting the service gateway (curl http://localhost:9000/api/hello/Alice%2FThat%2Fis%2Fmy%2Fname) I get the 404 as reported
• When hitting the service port directly (curl http://localhost:57797/api/hello/Alice%2FThat%2Fis%2Fmy%2Fname) I get the expected result: Hello, Alice/That/is/my/name!
• If I enable the experimental akka-http service gateway that was added in #894, I also get the expected result from port 9000 🎉

So I'm going to call this fixed by #894. We don't plan to continue fixing problems with the existing, netty-based service gateway, and the akka-http one will be the default in Lagom 1.4.

Until then, you can enable it in 1.3.7+ by:

• sbt adding lagomServiceGatewayImpl in ThisBuild := "akka-http" to your build.sbt or
• maven configuring the lagom maven plugin in the root POM with <serviceGatewayImpl>akka-http</serviceGatewayImpl>

1.3.7 has not been released yet, but there is a 1.3.7-RC1 pre-release build available in Maven Central that includes the new gateway, so if you need it urgently, you can use that.