<p dir="ltr"><br>
On 16 Oct 2013 13:09, <<a href="mailto:smainklh@free.fr">smainklh@free.fr</a>> wrote:<br>
><br>
> Thanks Maxim,<br>
> I'll contact their support in order to understand its behavior.</p>
<p dir="ltr">If you discover that it does indeed use POSTs in an nginx-incompatible way, you could use nginx to hack the request into something usable. [ NB I'd only do this for an absolutely immutable appliance; in any other situation I'd personally tell the devs their code was broken and we couldn't help: don't inherit other people's technical debt without a commitment to a fix! ]</p>

<p dir="ltr">There's a directive (proxy_method?) which changes the verb when used in a proxy_pass'd context.</p>
<p dir="ltr">You could just have a double pass through nginx, with the publicly-listening server{} solely being responsible for doing s/POST/PUT/ , before proxy_pass'ing to the actual webdav server via a <a href="http://127.0.0.0/8">127.0.0.0/8</a> address. Use a map to define the verb, I suggest. </p>

<p dir="ltr">If it's not clear from the above how to do this, let me know and I'll run up a test and guide you towards some config. I suggest it's not very difficult to do, however ;-)</p>
<p dir="ltr">Yes, this is an utterly horrible hack. No, I have never used it in production. Yes, there is an lie hidden in this paragraph.</p>
<p dir="ltr">Cheers, <br>
Jonathan<br>
</p>