Calling GET /path/?filter[name]=| returns 500

[cecemel]

Hello,

It seems I have a problem when executing a query similar to:

curl -v "http://host/path?filter[name]=|"

An HTTP error 500 is returned.
It suspect semtech/mu-identifier:1.8.0 to be the cause of the issue, as reverting back to semtech/mu-identifier:1.7.0 fixes the issue.
Other filter values seen to work too.

[madnificent]

Thank you for the issue. Curl doesn't seem to escape the supplied URL and the pipe character should be represented as %7C. In a browser encodeURIComponent can be used. I suppose 1.7.0 was more lenient in accepting URLs. Does it make sense to URL encode this request from your end?

[HugaertsDries]

I've noticed the same behavior when bumping versions of mu-dispatcher. But as we discussed earlier, this could be due to the fact that they are build on the same libraries and base constructs.

To give some more insight, here is a stacktrace:

dispatcher_1                                                   | 08:54:37.881 [info]  POST /melding
dispatcher_1                                                   | An error occurred: {:error,
dispatcher_1                                                   |  %Mint.HTTPError{
dispatcher_1                                                   |    module: Mint.HTTP1,
dispatcher_1                                                   |    reason: {:invalid_request_target, "/melding?type=|"}
dispatcher_1                                                   |  }}
identifier_1                                                   | 
identifier_1                                                   | 08:54:37.883 [info]  Sent 500 in 4ms
dispatcher_1                                                   | 
dispatcher_1                                                   | 08:54:37.883 [error] #PID<0.468.0> running PlugRouterDispatcher (connection #PID<0.467.0>, stream id 1) terminated
dispatcher_1                                                   | Server: localhost:90 (http)
dispatcher_1                                                   | Request: POST /melding?type=|
dispatcher_1                                                   | ** (exit) an exception was raised:
dispatcher_1                                                   |     ** (Plug.Conn.NotSentError) a response was neither set nor sent from the connection
dispatcher_1                                                   |         (plug_cowboy) lib/plug/cowboy/handler.ex:50: Plug.Cowboy.Handler.maybe_send/2
dispatcher_1                                                   |         (plug_cowboy) lib/plug/cowboy/handler.ex:13: Plug.Cowboy.Handler.init/2
dispatcher_1                                                   |         (cowboy) /app/deps/cowboy/src/cowboy_handler.erl:41: :cowboy_handler.execute/2
dispatcher_1                                                   |         (cowboy) /app/deps/cowboy/src/cowboy_stream_h.erl:296: :cowboy_stream_h.execute/3
dispatcher_1                                                   |         (cowboy) /app/deps/cowboy/src/cowboy_stream_h.erl:274: :cowboy_stream_h.request_process/3
dispatcher_1                                                   |         (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3

[HugaertsDries]

Thank you for the issue. Curl doesn't seem to escape the supplied URL and the pipe character should be represented as %7C. In a browser encodeURIComponent can be used. I suppose 1.7.0 was more lenient in accepting URLs. Does it make sense to URL encode this request from your end?

For now, I think this is the better approach