<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">

I remember something similar that was an issue when using Ceph RadosGW for Swift API

<div>when interaction through Horizon. This was solved directly in python-swiftclient which</div>

<div>Horizon was using [1], perhaps not any help but I just recalled it when reading this.</div>

<div><br>

</div>

<div>[1] https://review.opendev.org/c/openstack/python-swiftclient/+/722395<br>

<div><br>

<blockquote type="cite">

<div>On 4 Aug 2023, at 13:52, Christian Rohmann <christian.rohmann@inovex.de> wrote:</div>

<br class="Apple-interchange-newline">

<div>

<div>

<div class="moz-cite-prefix">On 04/08/2023 11:59, Artem Goncharov wrote:<br>

</div>

<blockquote type="cite" cite="mid:B84CA494-F5D2-48F1-94E4-82B9A4F43171@gmail.com">

<span style="white-space: pre-wrap"></span>

<pre class="moz-quote-pre" wrap="">Precisely. I always strongly disliked cases where REST methods are exposed under non service catalog provided base. This is an ugly grave full of corpses.

Idea with regex sounds like a least bad for me. Eventually finding /v1 and getting one level above.

</pre>

</blockquote>

<p>You mean using the path up until "v1" or "v[1-9]+"?<br>

But is v1 (or any version) always part of the endpoint url so it's possible to use this as a definitive delimiter?</p>

<p><br>

</p>

<p>In any case, could you then craft a patch for this one?<br>

Regards and thanks again,</p>

<p><br>

</p>

<p>Christian<br>

</p>

</div>

</div>

</blockquote>

</div>

<br>

</div>

</body>

</html>