Unexpected error with MessagesApi in custom error handler for client errors with [ or ] in the URI

[murosan]

When handling a client error request where characters like [ or ] are included in the URI, an unexpected error occurs when using MessagesApi.

Specifically, since the RequestHeader.attrs does not contain the Cookies attribute, accessing RequestHeader.cookies throws a NoSuchElementException.

Is this expected behavior? Should RequestHeader.cookies be considered unsafe to call in some contexts?

Related issue: #8113
It seems to be resolved.

Steps to reproduce:

1. Prepare files:

• conf/application.conf

play.http.errorHandler = "ErrorHandler"

• conf/messages

error.client_error = CLIENT_ERROR

• app/ErrorHandler.scala

import javax.inject.Inject
import javax.inject.Singleton

import scala.concurrent._

import play.api.http.HttpErrorHandler
import play.api.i18n.MessagesApi
import play.api.mvc._
import play.api.mvc.Results._

@Singleton
class ErrorHandler @Inject() (val messagesApi: MessagesApi) extends HttpErrorHandler {
  def onClientError(request: RequestHeader, statusCode: Int, message: String): Future[Result] = {
    println(request.attrs) // debug

    // Throws java.util.NoSuchElementException: key not found: Cookies
    val messages = messagesApi.preferred(request)

    val result = Status(statusCode)(messages("error.client_error"))
    Future.successful(result)
  }

  def onServerError(request: RequestHeader, exception: Throwable): Future[Result] = ???
}

2. Trigger a client error:

$ curl 'localhost:9000/\]' -I
HTTP/1.1 500 Internal Server Error
Date: Mon, 14 Jul 2025 10:51:54 GMT
Connection: close
Content-Length: 0

2025-07-14 19:57:42 ERROR o.apache.pekko.actor.ActorSystemImpl org.apache.pekko.actor.ActorSystemImpl(play-dev-mode) Internal server error, sending 500 response
java.util.NoSuchElementException: key not found: Cookies
	at scala.collection.immutable.Map$Map1.apply(Map.scala:263)
	at play.api.libs.typedmap.DefaultTypedMap.apply(TypedMap.scala:189)
	at play.api.mvc.RequestHeader.cookies(RequestHeader.scala:269)
	at play.api.mvc.RequestHeader.cookies$(RequestHeader.scala:269)
	at play.api.mvc.RequestHeaderImpl.cookies(RequestHeader.scala:396)
	at play.api.i18n.DefaultMessagesApi.preferred(Messages.scala:494)
	at ErrorHandler.onClientError(ErrorHandler.scala:16)
	at play.core.server.PekkoHttpServer.clientError$1(PekkoHttpServer.scala:344)
	at play.core.server.PekkoHttpServer.handleRequest(PekkoHttpServer.scala:352)
	at play.core.server.PekkoHttpServer.$anonfun$createServerBinding$1(PekkoHttpServer.scala:224)
	at org.apache.pekko.stream.impl.fusing.MapAsyncUnordered$$anon$31.onPush(Ops.scala:1443)
	at org.apache.pekko.stream.impl.fusing.GraphInterpreter.processPush(GraphInterpreter.scala:555)
	at org.apache.pekko.stream.impl.fusing.GraphInterpreter.processEvent(GraphInterpreter.scala:506)
	at org.apache.pekko.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:400)
	at org.apache.pekko.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:662)
	at org.apache.pekko.stream.impl.fusing.GraphInterpreterShell$AsyncInput.execute(ActorGraphInterpreter.scala:532)
	at org.apache.pekko.stream.impl.fusing.GraphInterpreterShell.processEvent(ActorGraphInterpreter.scala:637)
	at org.apache.pekko.stream.impl.fusing.ActorGraphInterpreter.org$apache$pekko$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:813)
	at org.apache.pekko.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:831)
	at org.apache.pekko.actor.Actor.aroundReceive(Actor.scala:547)
	at org.apache.pekko.actor.Actor.aroundReceive$(Actor.scala:545)
	at org.apache.pekko.stream.impl.fusing.ActorGraphInterpreter.aroundReceive(ActorGraphInterpreter.scala:729)
	at org.apache.pekko.actor.ActorCell.receiveMessage(ActorCell.scala:590)
	at org.apache.pekko.actor.ActorCell.invoke(ActorCell.scala:557)
	at org.apache.pekko.dispatch.Mailbox.processMailbox(Mailbox.scala:280)
	at org.apache.pekko.dispatch.Mailbox.run(Mailbox.scala:241)
	at org.apache.pekko.dispatch.Mailbox.exec(Mailbox.scala:253)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)

[mkurz]

I can reproduce, actually just calling messagesApi.preferred(request) in the onClientError method is enough to trigger the exception.

[mkurz]

WIP patch to fix the exception:

• [3.0.x] Make sure Cookies, Session, Flash always exists even if empty #13407

[mkurz]

The problem is:
Some client errors happen in a very early stage, when not even Pekko HTTP or Netty can process the request. In such cases, from the request no headers (and therefore no cookies) will be parsed - and then we will of course also not be able to determine the preferred language of the request. This is actually what #8113 is about.

However the exception

java.util.NoSuchElementException: key not found: Cookies

seems like that should not happen. IMHO instead we should always provide an emtpy Cookie attribute to at least avoid this exception.

As a workaround for now you could check if request.attrs contains RequestAttrKey.Cookies. Something like this:

  def onClientError(request: RequestHeader, statusCode: Int, message: String): Future[Result] = {
    // Some client errors happen in a very early stage, when not even Pekko HTTP or Netty can process the request.
    // In such cases, from the request no headers (and therefore no cookies) will be parsed - and then
    // we will of course also not be able to determine the preferred language of the request.
    val messages = request.attrs.get(RequestAttrKey.Cookies).map(_ => messagesApi.preferred(request))

    val result = Status(statusCode)(messages.map(_("error.client_error")).getOrElse(message))
    Future.successful(result)
  }

[mkurz]

Note to myself:
Pekko HTTP and Netty both enter clientError(...) and therefore will not call Server.getHandlerFor which would call copyRequestHeader which would set the request attrs.

[murosan]

Thanks for the quick follow-up and guidance!

[murosan]

I printed out request.attrs while debugging, and it might be better to also check for key existence when using session, flash, or id, since they might potentially fail too.

[mkurz]

... it might be better to also check for key existence when using session, flash, or id, since they might potentially fail too.

For the code you posted, just checking for cookies is enough.

Thanks to your report I implemented some improvements:

1. For now, up to Play 3.0.8, you need a workaround, like the one I posted
2. With Play's next patch release, 3.0.9, you will be able to use your code again - the exception will not occur anymore. However be aware with that patch release, the language set in the cookies (if set) will not be taken into account when looking up the preferred language - but at least the Accept-Language header from the request will (which is an improvement). Also request.id will be correctly set. See PRs [3.0.x] Make sure Cookies, Session, Flash always exists even if empty #13407, [3.0.x] Make sure Java's Session and Flash always exists even if empty req attrs (backport #13413) by @mkurz #13415 and [3.0.x] Generate and set the request-id as early as possible (backport #13409) by @mkurz #13423.
3. With Play's next major release, all the request's attrs will be correctly set in the onClientError method (req.cookies, req.flash, req.session) therefore messagesApi.preferred(request) will also check the language cookie. See PR request passed to onClientError now has cookies, flash and session set #13417