Re: [users@httpd] Strange WebDAV behavior on MKCOL for 1 client only
OK, thanks. Note that this same client works OK when it connects to Apache 2.4.6/OpenSSL/1.0.1e running on Linux. The HTTP 400 uri mismatch only happens when it connects to Apache 2.4.4/OpenSSL/1.0.1e on Windows. What would explain the difference? Todd On Mon, Aug 7, 2017 at 11:01 PM, Yehuda Katz wrote: > It looks like a problem with the implementation or configuration in the > client. > The actual source of your 400 error is this: > [auth_digest:error] [pid 3880:tid 1132] [client yyy.yyy.yyy.yy:61411] > AH01786: uri mismatch - does not > match request-uri > > This is because your Authorization header has - as the error message > clearly states - a mismatch. > > On your working connection: > Authorization: [...] uri="/webdav/dir1/dir2/dir3/dir4/dir5/dir6/", [...] > > On your broken connection: > Authorization: [...] uri="/webdav/dir1/dir2/dir3/dir4/dir5/dir6", [...] > > Note the missing trailing slash in your authorization header. > I suspect if you figure out why you are getting that, everything will > start working. > > - Y > > On Mon, Aug 7, 2017 at 6:22 PM, Todd Blum wrote: > >> OK, here is the MKCOL of a working client: >> >> >> _ >> >> [Mon Aug 07 14:47:04.258261 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(135): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> [getline-blocking] 0 readbytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(58): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): 48 bytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(100): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): MKCOL /webdav/dir1/dir2/dir3/dir4/dir5/dir6/ >> HTTP/1.1\r\n >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(135): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> [getline-blocking] 0 readbytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(58): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): 40 bytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(100): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): User-Agent: cadaver/0.23.3 neon/0.30.1\r\n >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(135): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> [getline-blocking] 0 readbytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(58): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): 16 bytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(100): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): Connection: TE\r\n >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(135): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> [getline-blocking] 0 readbytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(58): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): 14 bytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(100): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): TE: trailers\r\n >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(135): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> [getline-blocking] 0 readbytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(58): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): 35 bytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(100): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): Host: server.hostname.com\r\n >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(135): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> [getline-blocking] 0 readbytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(58): [client xxx.xxx.xxx.xx:45537] mod_dumpio: dumpio_in >> (data-TRANSIENT): 294 bytes >> [Mon Aug 07 14:47:04.329225 2017] [dumpio:trace7] [pid 3104:tid 1132] >> mod_dumpio.c(10
Re: [users@httpd] Strange WebDAV behavior on MKCOL for 1 client only
orization: Digest username="username", realm="DAV-upload", qop="auth", algorithm="MD5", uri="/webdav/dir1/dir2/dir3/dir4/dir5/dir6", nonce="1sn6zjBWBQA=124cb4760097cff44f4c97d8c9945a5a920a8c05", nc=0001, cnonce="ab08070e302202030f6049540f604955", response="64efa6e2ced2ae1ab4d9e5f64a60fcf8"\r\n [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(135): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_in [getline-blocking] 0 readbytes [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(58): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_in (data-TRANSIENT): 35 bytes [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(100): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_in (data-TRANSIENT): Host: server.hostname.com\r\n [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(135): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_in [getline-blocking] 0 readbytes [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(58): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_in (data-TRANSIENT): 2 bytes [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(100): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_in (data-TRANSIENT): \r\n [Mon Aug 07 14:48:34.517391 2017] [auth_digest:error] [pid 3880:tid 1132] [client yyy.yyy.yyy.yy:61411] AH01786: uri mismatch - does not match request-uri [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(164): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(58): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out (data-HEAP): 195 bytes [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(100): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out (data-HEAP): HTTP/1.1 400 Bad Request\r\nDate: Mon, 07 Aug 2017 21:48:34 GMT\r\nServer: Apache/2.4.4 (Win64) OpenSSL/1.0.1e\r\nContent-Length: 226\r\nConnection: close\r\nContent-Type: text/html; charset=iso-8859-1\r\n\r\n [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(164): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(58): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out (data-HEAP): 226 bytes [Mon Aug 07 14:48:34.517391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(100): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out (data-HEAP): \n\n400 Bad Request\n\nBad Request\nYour browser sent a request that this server could not understand.\n\n\n [Mon Aug 07 14:48:34.518391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(58): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out (metadata-EOS): 0 bytes [Mon Aug 07 14:48:34.518391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(164): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out [Mon Aug 07 14:48:34.518391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(58): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out (metadata-EOR): 0 bytes [Mon Aug 07 14:48:34.518391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(164): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out [Mon Aug 07 14:48:34.518391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(58): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out (metadata-FLUSH): 0 bytes [Mon Aug 07 14:48:34.518391 2017] [dumpio:trace7] [pid 3880:tid 1132] mod_dumpio.c(58): [client yyy.yyy.yyy.yy:61411] mod_dumpio: dumpio_out (metadata-EOC): 0 bytes _ Todd On Mon, Aug 7, 2017 at 5:07 PM, Yehuda Katz wrote: > Try mod_dumpio or a packet capture to see what else is different about the > request. > > - Y > > On Mon, Aug 7, 2017 at 3:53 PM, Todd Blum wrote: > >> Hello, >> >> I have Apache mod_dav running on Windows 2012. >> >> When a webDAV enabled application connects and tries to MKCOL on a >> directory that already exists, it receives an HTTP 400: >> >> >> >> >> yyy.yyy.yyy.yy - username [07/Aug/2017:11:00:03 -0700] "MKCOL >> /webdav/dir1/dir2/dir3/dir4/dir5/dir6/ HTTP/1.1" 400 226 >> >> >> >> >> However, all other clients are receiving an HTTP 405 when they issue a >> MKCOL for a directory that already exists: >> >> >> >> >> xxx.xxx.xxx.xx - username [07/Aug/2017:12:32:16 -0700] "MKCOL >> /webdav/dir1/dir2/dir3/dir4/dir5/dir6/ HTTP/1.1" 405 253 >> >> >> >> >> The application is dependent on receiving a 405 in this scenario, has >> anyone else had this situation before? >> >> >> Todd >> >> >
[users@httpd] Strange WebDAV behavior on MKCOL for 1 client only
Hello, I have Apache mod_dav running on Windows 2012. When a webDAV enabled application connects and tries to MKCOL on a directory that already exists, it receives an HTTP 400: yyy.yyy.yyy.yy - username [07/Aug/2017:11:00:03 -0700] "MKCOL /webdav/dir1/dir2/dir3/dir4/dir5/dir6/ HTTP/1.1" 400 226 However, all other clients are receiving an HTTP 405 when they issue a MKCOL for a directory that already exists: xxx.xxx.xxx.xx - username [07/Aug/2017:12:32:16 -0700] "MKCOL /webdav/dir1/dir2/dir3/dir4/dir5/dir6/ HTTP/1.1" 405 253 The application is dependent on receiving a 405 in this scenario, has anyone else had this situation before? Todd
[users@httpd] Getting 'Fatal Handshake Failure' with WebDAV client
Hello, I've set up Apache 2.4.27 with mod_dav, running on Windows 2012 on an Apache Haus build. All of my WebDAV clients authenticate OK to it, except for one. When this WebDAV client connects to Apache 2.4.27 built with OpenSSL 1.1.0f, Wireshark captures the following packet right after 'Client Hello': 'Alert (level: Fatal, Description: Handshake Failure)' Wireshark doesn't show any 'Handshake Failure' packets when it connects to Apache 2.4.27/OpenSSL 1.0.2l, but it doesn't establish an SSL/TLS session to that either. The 'Client Hello' packet for the client is as follows: ___ No. TimeSourceDestination Length Protocol Src Prt Dst Prt Info 4 2017-07-25 14:58:26.128 xxx.xxx.xxx.xxxxx.xxx.xxx.xx 180SSLv262572 443 Client Hello Frame 4: 180 bytes on wire (1440 bits), 92 bytes captured (736 bits) on interface 0 Null/Loopback Internet Protocol Version 4, Src: xxx.xxx.xxx.xx (xxx.xxx.xxx.xx), Dst: xxx.xxx.xxx.xx (xxx.xxx.xxx.xx) Transmission Control Protocol, Src Port: 62572 (62572), Dst Port: 443 (443), Seq: 1, Ack: 1, Len: 48 Secure Sockets Layer SSLv2 Record Layer: Client Hello [Version: SSL 2.0 (0x0002)] Length: 46 Handshake Message Type: Client Hello (1) Version: SSL 3.0 (0x0300) Cipher Spec Length: 21 Session ID Length: 0 Challenge Length: 16 Cipher Specs (7 specs) Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x0a) Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x05) Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x04) Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080) Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) Cipher Spec: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0xff) Challenge ___ I've even configured httpd-ssl.conf with the following with no luck: # old configuration, tweak to your needs SSLProtocol all SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP SSLHonorCipherOrder on SSLCompression off SSLSessionTickets off Has anyone else encountered something like this? Todd -- Todd Blum http://www.toddblum.org - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Migrate webDAV on IIS to Apache?
Hi Marat, Thanks, I honestly didn't know. Is Apache the only open source WebDAV server for Windows or are there others? Todd On Jul 22, 2017 1:11 AM, "Marat Khalili" wrote: Hello, WebDAV is just file access protocol, and Apache supports. Neither server holds any data, it just rests in the filesystem or can be managed by some application. Depending on what you're accessing you can even run Apache and IIS in parallel. What exactly you're afraid to lose? -- With Best Regards, Marat Khalili On July 22, 2017 12:06:43 AM GMT+03:00, Todd Blum wrote: > Hello, > > I'm currently have IIS set up to run webDAV. Is it possible to migrate to > webDAV on Apache instead without losing any data? > > Todd > > -- > Todd Blum > http://www.toddblum.org > > > -- > > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
[users@httpd] Migrate webDAV on IIS to Apache?
Hello, I'm currently have IIS set up to run webDAV. Is it possible to migrate to webDAV on Apache instead without losing any data? Todd -- Todd Blum http://www.toddblum.org - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
