On Saturday, 26 August 2017 04:37:44 PDT René J. V. Bertin wrote:
> I found the explanation after I discovered that one can compare the
> effective request headers with the ones from the reply in the slot that
> gets called after the request has completed.
>
> In the end I had slightly different settings in my filtering proxy on the 2
> machines (Privoxy); connecting now works fine when I don't try to hide the
> referer info. A bit surprising as that information isn't being added as far
> as I can tell...
Ok, so a man-in-the-middle. I'd never have guessed that.
> > Can you check why your HTTP
> > server decided to send 403 Forbidden?
>
> I'd love to know how, without having access to it. A packet snooper maybe
> (never used those), to see what's really being exchanged?
Right. But if you have something in the middle, you have to check both sides
of it.
> > Other recommendations:
> >
> > Remove your code that uses QNetworkConfigurationManager. You should always
> > assume you're already connected.
>
> Thanks, I was wondering why the code didn't make that assumption indeed.
> What also surprises me is that a wired connection shows up as an invalid
> QNetworkConfiguration and an UnknownAccessibility QNAM capability.
I want to remove the bearer API for Qt 6. We'll discuss in the next two years
to see if that makes sense.
> > Replace your QString-based URL construction with QUrlQuery.
>
> I take it you mean the construction of the POST data QByteArray used in the
> QNetworkRequest::post() calls?
Yes.
> I could do
>
> QUrlQuery postData;
> postData.addQueryItem(QStringLiteral("a"), QStringLiteral("update"));
> postData.addQueryItem(QStringLiteral("s"), KEYDB_SERVER_API);
> postData.addQueryItem(QStringLiteral("p"), KEYDB_ACCESS);
> postData.addQueryItem(QStringLiteral("v"), APPVERSION_STR);
> postData.addQueryItem(QStringLiteral("d"), QString::number(debug));
>
> and then
>
> m_netReply = m_accessManager->post(request, postData.toString());
>
> or
>
> m_netReply = m_accessManager->post(request, postData.query());
>
> but I don't see the option to obtain the intended encoding and I also doubt
> if this would be an improvement.
What's wrong with the encoding that QUrlQuery produces for you? HTTP Post
defaults to application/x-www-form-urlencoded, which is what QUrlQuery
produces for you.
You just have to be careful with spaces and + signs.
> This could be nice though:
>
> QUrlQuery postData = {{QStringLiteral("a"), QStringLiteral("update")},
> , {QStringLiteral("s"), KEYDB_SERVER_API}
> , {QStringLiteral("p"), KEYDB_ACCESS}
> , {QStringLiteral("v"), APPVERSION_STR}
> , {QStringLiteral("d"), QString::number(debug)}};
>
> (or using a << operator) ;)
Submit a patch. QUrlQuery precedes initializer_lists.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
