That is mostly correct, an explicit redirect is intentionally not implemented.
The general case is that the scope of the rewriter is entirely encapsulated in
the request
portion of the lifecycle, it can only indirectly influence the result.
Even errors thrown are don't generate a response directly, they are handled by
the user
supplied error handler, and a fallback to the system error handler.
The best options are to either use <dispatch> to send to an javascript or
xquery endpoint
that calls xdmp:redirect-request() , or to use an error handler which can do
the same,
and use the <error> action (with whaterver details you want) which will invoke
your error handler.
---- Option
If the endpoint called by some kind of program or script instead, including
JavaScript in a browser,
theres another option -- You can evaluate 'ad hoc' javascript and xquery .
This is more difficult, error prone and potentially a security issue -- but no
more or less then
other forms of 'xquery injection' -- so should be treated as such (the above
options are generally
simplier, safer, and as efficient).
--- XDBC internal endpoints (/eval,/invoke,/insert,/spawn)
While the rewriter itself cannot 'rewrite to a redirect',
All HTTP servers support the XCC protocol -- in any request. The rewriter can
indicate that
a request is handled by XCBC by rewriting to the XDBC endpoints and setting the
xdbc attribute
in the dispatch element.
You can see this in action on port 8000, or in any newly created REST server.
If you use a rewriter with a block similar to the 8000-rewriter.xml
<!-- XDBC -->
<match-path any-of="/eval /invoke /spawn /insert">
<trace event="Rewriter Evaluator">$0</trace>
<set-error-format>compatible</set-error-format>
<dispatch xdbc="true">$0</dispatch>
</match-path>
<!-- XDBC -->
You can create an 'eval' to call xdmp:redirect-request
It needs to be a POST with url encoded form data
E.g. : (with authentication set to app-level to simplify the demo)
$ curl -i --data-urlencode
'xquery=xdmp:redirect-response("http://www.google.com";)'
http://localhost:8000/eval
HTTP/1.1 302 Found
Server: MarkLogic 8.0-20151109DL1
Location: http://www.google.com
Set-Cookie: TxnID=null; path=/
Content-Length: 0
Connection: Keep-Alive
Keep-Alive: timeout=5
---------------
-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
d...@marklogic.com
Phone: +1 812-482-5224
Cell: +1 812-630-7622
www.marklogic.com
-----Original Message-----
From: general-boun...@developer.marklogic.com
[mailto:general-boun...@developer.marklogic.com] On Behalf Of Florent Georges
Sent: Sunday, November 15, 2015 9:00 AM
To: MarkLogic Developer Discussion <general@developer.marklogic.com>
Subject: [MarkLogic Dev General] Redirect declaratively from the XML Rewriter
Hi,
Using the new declarative Rewriter XML feature [1][2], it seems the only
actions possible are either dispatching to an actual module to handle the
request, or throwing an error.
It seems it is not possible to issue a redirect declaratively. For instance,
something like:
<match-path matches="^/old/place$">
<redirect>/new/place</redirect>
</match-path>
in order to issue a 307 (or 302 in HTTP/1.0) to the user, in a declarative way,
directly from the rewriter.
Is that the case, or did I miss anything?
Regards,
--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/
[1] https://developer.marklogic.com/features/enhanced-http
[2] https://docs.marklogic.com/guide/app-dev/XMLrewriter
_______________________________________________
General mailing list
General@developer.marklogic.com
Manage your subscription at:
http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
General@developer.marklogic.com
Manage your subscription at:
http://developer.marklogic.com/mailman/listinfo/general
