Hi Jan, Thanks for the observation. It was a bug: cookie headers need to be dealt with differently than other headers. It is fixed in the latest snapshot [1,2]. Best, Christian [1] https://github.com/BaseXdb/basex/commit/1d3fe97a623ae86d848c6af2144f091cb7a5... [2] https://files.basex.org/releases/latest/ ________________________________________ Von: Jan Ctibor via BaseX-Talk <basex-talk@mailman.uni-konstanz.de> Gesendet: Mittwoch, 1. Juli 2026 10:06 An: basex-talk@mailman.uni-konstanz.de Betreff: [basex-talk] Multiple Set-Cookies in http:response Dear, Christian, thank you for explaining the thing with web:forward, it makes perfectly sense. And I have another issue right away: when I send an http:response element with multiple Set-Cookie headers as a response (which should be perfectly ok), only the last one is actually send back to the browser: What I send: session:set("id","value_id"), <rest:response xmlns:rest="http://exquery.org/ns/restxq"> <http:response xmlns:http="http://expath.org/ns/http-client" status="200"/> <http:header name="Set-Cookie" value="cookie_1=value_1;"/> <http:header name="Set-Cookie" value="cookie_2=value_2;"/> <http:header name="Set-Cookie" value="cookie_3=value_3"/> </http:response> </rest:response> What browser recieves: HTTP/1.1 200 OK Server: Jetty(12.1.5) Date: Wed, 01 Jul 2026 07:49:50 GMT Content-Type: application/xml; charset=UTF-8 Server-Timing: parse;dur=7.04 ms,compile;dur=0.65 ms,optimize;dur=0.02 ms,evaluate;dur=0.03 ms,serialize;dur=0.0 ms Set-Cookie: cookie_3=value_3 Content-Length: 0 It also affects the automatically sent session cookie, which does not reach the browser, if there is some Set-Cookie header present in the http:response. Is it a bug, or an intendet behavior? Should a different approach be used for setting multiple cookies? Best regards and sorry for not sending both issues in one e-mail, but I have found this one only yesterday. Jan Ctibor ---------- Původní e‑mail ---------- Od: Christian Grün via BaseX-Talk <basex-talk@mailman.uni-konstanz.de> Komu: basex-talk@mailman.uni-konstanz.de <basex-talk@mailman.uni-konstanz.de>, Jan Ctibor <CtiborJan@seznam.cz> Datum: 29. 6. 2026 16:16:38 Předmět: [basex-talk] Re: web:forward with absolute URL Dear Jan, Thanks for the bug report. We have replaced the unexpected error with a controlled error message [1].
Is the web:forwardfunction actually supposed to also work with absolute URLs, or only with relative URLs within the server?
With web:forward, server-side endpoints can be addressed, but no external URIs that are out of our control. To make that happen, you will need to use web:redirect. It is almost always the better choice: we even think about getting rid of web:forward, now that multiple server-side operations can be represented with multiple job:execute calls. Hope this helps, Christian [1] https://files.basex.org/releases/latest/ ________________________________________ Von: Jan Ctibor via BaseX-Talk <basex-talk@mailman.uni-konstanz.de> Gesendet: Sonntag, 28. Juni 2026 21:32 An: basex-talk@mailman.uni-konstanz.de Betreff: [basex-talk] web:forward with absolute URL Hello, BaseX team, I have found recently, that the web:forward function (in both BaseX 12.1 and 12.4, have not checked with older versions), when called with an absolute URL, triggers an error in jetty (see below). Best regards, Jan Ctibor P. S. Is the web:forwardfunction actually supposed to also work with absolute URLs, or only with relative URLs within the server? Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk@mailman.uni-konstanz.de Version: BaseX 12.4 Java: Red Hat, Inc., 25.0.3 OS: Linux, amd64 Stack Trace: org.eclipse.jetty.http.BadMessageException: 400: Ambiguous URI empty segment at org.eclipse.jetty.ee9.nested.Dispatcher.forward(Dispatcher.java:186) at org.eclipse.jetty.ee9.nested.Dispatcher.forward(Dispatcher.java:145) at org.basex.http.HTTPConnection.forward(HTTPConnection.java:260) at org.basex.http.restxq.RestXqResponse.finish(RestXqResponse.java:155) at org.basex.http.web.WebResponse.create(WebResponse.java:63) at org.basex.http.restxq.RestXqServlet.run(RestXqServlet.java:70) at org.basex.http.BaseXServlet.service(BaseXServlet.java:68) at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:587) at org.eclipse.jetty.ee9.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1415) at org.eclipse.jetty.ee9.servlet.ServletHolder.handle(ServletHolder.java:783) at org.eclipse.jetty.ee9.servlet.ServletHandler.doHandle(ServletHandler.java:528) at org.eclipse.jetty.ee9.nested.ScopedHandler.handle(ScopedHandler.java:125) at org.eclipse.jetty.ee9.security.SecurityHandler.handle(SecurityHandler.java:603) at org.eclipse.jetty.ee9.nested.HandlerWrapper.handle(HandlerWrapper.java:124) at org.eclipse.jetty.ee9.nested.ScopedHandler.nextHandle(ScopedHandler.java:195) at org.eclipse.jetty.ee9.nested.SessionHandler.doHandle(SessionHandler.java:612) at org.eclipse.jetty.ee9.nested.ScopedHandler.nextHandle(ScopedHandler.java:193) at org.eclipse.jetty.ee9.nested.ContextHandler.doHandle(ContextHandler.java:1047) at org.eclipse.jetty.ee9.nested.ScopedHandler.nextScope(ScopedHandler.java:162) at org.eclipse.jetty.ee9.servlet.ServletHandler.doScope(ServletHandler.java:483) at org.eclipse.jetty.ee9.nested.ScopedHandler.nextScope(ScopedHandler.java:160) at org.eclipse.jetty.ee9.nested.SessionHandler.doScope(SessionHandler.java:589) at org.eclipse.jetty.ee9.nested.ScopedHandler.nextScope(ScopedHandler.java:160) at org.eclipse.jetty.ee9.nested.ContextHandler.doScope(ContextHandler.java:962) at org.eclipse.jetty.ee9.nested.ScopedHandler.handle(ScopedHandler.java:123) at org.eclipse.jetty.ee9.nested.ContextHandler.handle(ContextHandler.java:1731) at org.eclipse.jetty.ee9.nested.HttpChannel$RequestDispatchable.dispatch(HttpChannel.java:1586) at org.eclipse.jetty.ee9.nested.HttpChannel.dispatch(HttpChannel.java:737) at org.eclipse.jetty.ee9.nested.HttpChannel.handle(HttpChannel.java:520) at org.eclipse.jetty.ee9.nested.ContextHandler$CoreContextHandler$CoreToNestedHandler.handle(ContextHandler.java:3059) at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1226) at org.eclipse.jetty.server.Server.handle(Server.java:197) at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:788) at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:420) at org.eclipse.jetty.server.internal.HttpConnection$FillableCallback.succeeded(HttpConnection.java:1809) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:54) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:204) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:317) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:1009) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1240) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1194) at java.base/java.lang.Thread.run(Thread.java:1474)