Can I use/parse query parameters with this library? #156
Replies: 2 comments
-
Hi! Thank you for the question, but it is indeed a deliberate choice to leave query parameters outside this library. The scope for this library is pretty fine grained and query params should ideally not be used for routing decisions so I left these out. I'm also going to move this to a discussion as at the moment I don't intend to support query params within the core library. Best, |
Beta Was this translation helpful? Give feedback.
-
That is fine. At the moment, I have a setup like this: module Server = struct
let routes =
Routes.one_of
[
my_route;
]
let unwrap_result = function
| Routes.NoMatch ->
Logs.err (fun m -> m "found no match for route");
Cohttp_eio.Server.respond_string
~status: `OK
~body: (Pure_html.to_string Not_found.v)
()
| FullMatch r -> r
| MatchWithTrailingSlash r -> r
open Cohttp_eio.Server
let handler
: conn ->
Http.Request.t ->
body ->
response IO.t
= fun _conn { resource; _ } _body ->
unwrap_result @@ Routes.match' ~target: resource routes
let run ~env ?(port = 8080) () =
let@ sw = Eio.Switch.run ?name: None in
let port = ref port in
let socket =
Eio.Net.listen
env#net
~sw
~backlog: 128
~reuse_addr: true
(`Tcp (Eio.Net.Ipaddr.V4.loopback, !port))
and server = Cohttp_eio.Server.make ~callback: handler ()
in
Cohttp_eio.Server.run socket server ~on_error: log_warning
end So is the recommended approach to split the path from the query before I use |
Beta Was this translation helpful? Give feedback.
-
From this line it seems that the expected behavior of the matcher is to discard the query parameters. I am wondering about your thoughts on this. Would you be interested in a contribution that extends the scope of this library to handle this case? Or should I just work around it with a custom route somehow?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions