Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-84162

QNetworkReply for request with a custom verb never emits finished() signal after being redirected with status code 301

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • P2: Important
    • 5.15.1
    • 5.14.2
    • Network: HTTP
    • None
    • Linux/X11
    • 306ebe03ea13c6e0ac8de46e46d0859384954567 (qt/qtbase/dev) 3666a66b0c741df75007c84e7e7f0c59e98fa24f (qt/qtbase/5.15)

    Description

      Disclaimer: I am not an expert with HTTP and maybe I'm simply doing something horribly wrong. So please bear with me, if this report is stupid

      I am using a QNetworkAccessManager in my app to sync files via WebDAV. This means I use a combination of the standard HTTP verbs (GET, POST, etc) as well as custom ones (PROPFIND, MKCOL). Up to now my app did not handle redirections at all (surprisingly, also up to now no one seemed to have noticed this).

      A user recently reported some issues when trying to use my app with his server (I unfortunately don't have too much insight in what he is using, but from what I understood it is basically a shared hoster with nginx running with some default built in WebDAV implementation). From the provided logs I noticed that the server replied to some requests with a code 301 (permanently moved).

      Looking at the documentation, I hoped that this issue would be as easy to solve as calling **

      m_networkAccessManager->setRedirectPolicy(QNetworkRequest::NoLessSafeRedirectPolicy)

      on my QNAM. In fact, afterwards the replies did not finish with an error code. However, I started to see other, rather strange results. In my code, I use the following function to blocking-wait for a reply to finish (yes, shame on me, eventually I'll refactor the code to be fully even driven):

      void WebDAVClient::waitForReplyToFinish(QNetworkReply *reply)
      {
          Q_CHECK_PTR(reply);
          QEventLoop loop;
          connect(reply, &QNetworkReply::finished, &loop, &QEventLoop::quit);
          connect(reply, SIGNAL(error(QNetworkReply::NetworkError)), &loop, SLOT(quit()));
          connect(reply, &QNetworkReply::redirected, [=]() {
              qCDebug(log) << "Redirected to" << reply->url();
          });
          qCDebug(log) << "Waiting for" << reply->url()
                       << reply->request().attribute(QNetworkRequest::CustomVerbAttribute).toByteArray()
                       << "to finish";
          loop.exec();
      }
      

      As long as there are no redirects, this code works flawlessly. Additionally, it seems that for standard verbs it also works as expected (e.g. I tried to put a GET request to http://qt.io as a dummy call in my code and it got properly redirected to https://www.qt.io/ and the target page's code is downloaded properly via the reply).

      However, for any custom verb (like PROPFIND, MKCOL), I see the following behavior:

      • The redirected() signal of the reply is emitted.
      • However, afterwards the reply never emits it's finished() signal.

      Due to the way I coded it, this means the app sits there and waits forever. I will change my code (to use manual redirect handling for the time being), however, my expectation of QNAM would be one of the two:

      • Either (this is - from my point of view - the ideal case), QNAM handles the redirect also for custom verbs, downloads (or uploads) whatever has been requested and finally the appropriate QNetworkReply emits it's finished() signal. Or...
      • It does not handle the redirection for such verbs at all but still the finished() signal is emitted, so any application logic can continue.

      I hope that all makes a bit of sense. If I can provide any more input, please let me know.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            manordheim Mårten Nordheim
            mhoeher Martin Höher
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes