[Interest] Code using QNetworkAccessManager::post() working on Linux but not on Mac

Thiago Macieira thiago.macieira at intel.com
Sat Aug 26 19:48:05 CEST 2017

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?


> 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

More information about the Interest mailing list