Eygene Ryabinkin schrieb:
Julian, good day.
Tue, Apr 03, 2007 at 06:52:59PM +0200, Julian Reschke wrote:
Eygene Ryabinkin schrieb:
Good day!
Sorry for rather long letter, but this is the summary from numerous
discuissions and I really tried to make it short.
...
Hi.
RFC2518bis allows the Destination header to be just an absolute path for
exactly that reason (see
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html#destination-header>).
Pardon for my stupideness, but what 'that reason' you are talking
about? The previous letter was rather long and I fail to identify
the exact point you're commenting. Could you, please, elaborate
a bit?
Sorry.
What I meant by "reason" was the fact that the "Destination" header (and
some aspects of the "If" header) require absolute URIs, which is
problematic when there's a reverse proxy in the transmission path. All
the issues around to rewrite or not to rewrite headers go away once
these headers use absolute paths (well, as long as the reverse proxy
doesn't also rewrite paths, but I would claim that this is nearly
impossible to get right with WebDAV).
So this is really one of the few things why RFC2518bis support would be useful
in practice (if clients start to take advantage of it).
But even if the 'Destination' is just the absolute path, then in
the reversy proxying from the http://frontend/dir-one to the
http://backend/some-long-path/dir-two we will still need to rewrite
that absolute path. It is not very uncommon to see the reverse
Right (see above). But if you also rewrite paths, you will also need to
rewrite all multistatus response bodies. Thus is why I assumed nobody is
traing that.
proxying for the different absolute paths on the frontend and backend
servers: I've seen some that were due to some software weirdness
(for example, two proxied Wiki instances that require the /wiki
path to be present in both of them) or some legacy configuration
that can not be readily changed due to the poor design. Am I missing
some point?
I haven't seen reverse proxying with path rewriting working for WebDAV
so far. My assumption was that the easy variant (host/port) is already
hard enough, and the intent of those changes in RFC2518bis is to make at
least this case simpler.
Best regards, Julian
