Thiago Macieira wrote:
>> 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.
I was
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 t
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?
Q
On Saturday, 26 August 2017 15:36:08 PDT René J. V. Bertin wrote:
> > 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.
>
> I have no idea. I just note that the data with the cu
Thiago Macieira wrote:
>> 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.
I'd never have thought of that explanation either, and don't really understand
it. If no referer header is added
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 s
Thiago Macieira wrote:
> Was there a request to the server in the first place? Or did QNAM fail without
> sending a request?
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
On Friday, 25 August 2017 06:05:15 PDT René J.V. Bertin wrote:
> I'm porting a Qt5-based little downloader from MS Windows to Mac+Linux (both
> have Qt 5.8.0). It uses a POST operation to authenticate with the server,
> using code that works fine on MSWin and Linux. On Mac, I keep getting a
> Forbi
Hi,
I'm porting a Qt5-based little downloader from MS Windows to Mac+Linux (both
have Qt 5.8.0). It uses a POST operation to authenticate with the server, using
code that works fine on MSWin and Linux. On Mac, I keep getting a Forbidden
reply from the server (the MSWin executable functions fine
