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

Thiago Macieira thiago.macieira at intel.com
Sun Aug 27 18:57:15 CEST 2017


On Sunday, 27 August 2017 01:47:49 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> >> I have no idea. I just note that the data with the current call is
> >> different from what QUrlQuery gives; I didn't try the QUrlQuery result
> >> because I have no idea of the potential implications of those
> >> differences.
> > 
> > Can you elaborate what comes out differently?
> 
> QUrl::toPercentEncoding() encodes anything that doesn't look like isalnum
> 
> unencoded data: "a=update&s=2.0&p=passphras/r=(Fake^Password)&v=2.1.1.0&d=0"
> QUrl::toPercentEncoding(dataToEncode, "&=") :
> "a=update&s=2.0&p=passphras%2Fr=%28Fake%5EPassword%29&v=2.1.1.0&d=0"
> QUrlQuery::toString() :
> "a=update&s=2.0&p=passphras/r%3D(Fake%5EPassword)&v=2.1.1.0&d=0"
> QUrlQuery::query() :
> "a=update&s=2.0&p=passphras/r%3D(Fake%5EPassword)&v=2.1.1.0&d=0"
> 
> But again, even if those are exchangeable, why is QUrlQuery better? As far
> as I can tell I'd be using that class or QUrl to construct something that's
> not an URL. 

Because you're encoding something that is part of a URL's query. It's the same 
encoding.

The difference is that the RFC allows certain characters to appear either 
encoded or unencoded (the case of the parentheses), while some others must 
always be encoded (the "^") and others must always be unencoded (alphabetic, 
numbers, etc.). QUrlQuery knows about that and leaves those characters alone, 
but QUrl::toPercentEncoding doesn't know any better and will encode them. 
Sometimes that encoding changes meaning.

The only thing that looks weird there is that QUrlQuery encoded the '=' in the 
value of "p" parameter. It needs to encode the '=' if it is in the key, but 
not the value.

> Something that could be done directly by
> {QString,QByteArray}::toPercentEncoding() if such a method existed. And at
> best I'd be replacing 2 calls to construct that data buffer with 2
> different calls. Or else 2 lines with 7.

Yes, but they are much more understandable 7 lines, rather tha one cryptic 
string. Not to mention that you need to get your encoding right manually, 
whereas QUrlQuery will do the right job for you.

> Maintainability is maybe a bit better with the API where each key/value pair
> is added individually. But this is not a case where anything is likely to
> change (or be refactored) often except possibly for the things that are
> already defined in macros.

Ok, now try setting a password that contains "&p=".

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Interest mailing list