-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Tres Seaver tseaver at palladion.com writes:
There is no way to tell the difference between a WebDAV GET and a
normal browser GET, period: the specs explicitly, deliberately
overload the GET verb.
Hence the IANA-assigned
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Tres Seaver tseaver at palladion.com writes:
There is no way to tell the difference between a WebDAV GET and a
normal browser GET, period: the specs explicitly, deliberately
overload the GET verb.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
Martin Aspeli wrote:
Can anyone explain why that condition is there? Otherwise, I'll rip it
out. ;-)
As I recall, this code is convoluted because it's hard to tell whether
an HTTP request is a WebDAV request. If there
Tres Seaver tseaver at palladion.com writes:
There is no way to tell the difference between a WebDAV GET and a
normal browser GET, period: the specs explicitly, deliberately
overload the GET verb.
Hence the IANA-assigned WebDAV source port[1] (9800) (which *we*
requested) in order to
Martin Aspeli wrote:
Martin Aspeli wrote:
Martin Aspeli wrote:
Hi,
In my travails through the ZPublisher and WebDAV, I've come up with
another fun thing.
As far as I can tell, traversal via acquisition doesn't make any sense
for a WebDAV request. If I have /foo and /bar, but not
Martin Aspeli wrote:
Can anyone explain why that condition is there? Otherwise, I'll rip it
out. ;-)
As I recall, this code is convoluted because it's hard to tell whether
an HTTP request is a WebDAV request. If there is now a way to clearly
distinguish WebDAV requests, then I imagine this
Shane Hathaway shane at hathawaymix.org writes:
Martin Aspeli wrote:
Can anyone explain why that condition is there? Otherwise, I'll rip it
out.
As I recall, this code is convoluted because it's hard to tell whether
an HTTP request is a WebDAV request. If there is now a way to