On 2021-05-05, T. Ribbrock <[email protected]> wrote: > Hi all, > > this may be a long shot, but I'm looking for someone who can give me a > few pointers (if this is better posted to another list, please let me > know as well). > > TL;DR: I am running into issues with a webdav/caldav client > connecting to a Nextcloud instance running on OpenBSD httpd, so someone > with a more intimate knowledge of httpd would probably already be a > great help.
This is not a bad place to ask. Your description is good but anyone looking into what's up will want to test, so if you could include the test tools and a description of setup needed to reproduce that would help. Including the tcpdump traces would help too. Don't worry about the mail being long. > Using tcpdump on the test server, I was able to determine some > differences between the two test clients: > > The Perl-client seems to send both http-headers and the XML-body for the > PROPFIND in one go, gets a 401 response and then re-issues the request > with authorisation (which then succeeds). > > The Qt-client sends the http-headers first in one TCP-segment (I'm not > too good on terminology...). Once that has happened, httpd already sends > back the 401 - and *then* the Qt-client sends the XML-body in a second > TCP-segment, causing the "400 Bad Request" response (I presume because > httpd is expecting new headers at this point, not a content body). It makes no difference to the HTTP protocol whether headers and body are in separate TCP segments, but some software may handle things wrongly. httpd uses libevent and it wouldn't be the first time libevent-based software has problems with data in separate TCP segments (I have a feeling we might have had a problem with ftp-proxy related to this but can't find any details, perhaps it was never fixed), > What I am now trying to figure out (and I neither know the relevant > standards nor httpd well enough to do so) is whether this is something > weird on the Qt side - or on the OpenBSD/httpd side so I can eventually > provide input to the right people to hopefully get this fixed at some > point. Pretty sure it will be on the httpd side.
