Strange GET request reply - now posted code

[cpper]

I removed the QString conversion and now get no output at all :/

I can't understand what is wrong, I'm making the request with the exact parameters as show in the browser, but the reply is still empty.

Chrome screenshot:

My code:

QNetworkRequest* wtr=new QNetworkRequest(QUrl("http://tx3.travian.de/dorf1.php"));


  QString getCookie=QString(reply->rawHeader("Set-Cookie"));
  getCookie.remove("path=/; httponly");
  getCookie.remove("\n");
  getCookie.chop(2);
  getCookie.push_front(sid+"; ");

// after these operations, getCookie has the exact same syntax as in the screenshot

   wtr->setRawHeader("Accept","text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8");
   wtr->setRawHeader("Accept-Encoding","gzip, deflate, sdch");
   wtr->setRawHeader("Accept-Language","en-US,en;q=0.8,de;q=0.6,ro;q=0.4,fr;q=0.2");
   wtr->setRawHeader("Cache-Control","no-cache");
   wtr->setRawHeader("Cookie",getCookie.toUtf8());
   wtr->setRawHeader("Connection","keep-alive");
   wtr->setRawHeader("Host","tx3.travian.de");
   wtr->setRawHeader("Pragma","no-cache");
   wtr->setRawHeader("Referer","http://tx3.travian.de/");
   wtr->setRawHeader("Upgrade-Insecure-Requests","1");
   wtr->setRawHeader("User-Agent","Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36");


   connect(qnam,&QNetworkAccessManager::finished,this,&MainWindow::fin);
   qnam->get(*wtr);
}

[jsulm]

@cpper What is the size of the QByteArray you get?

[SGaist]

Side note, there's no need to create your QNetworkRequest on the heap, just use a local variable.

[cpper]

@SGaist, I knew that, I made it on the heap this time just to be 100% sure I rule out any problem with the object being deleted before it's used.

@jsulm reply->readAll().size(); returns 11087.

[jsulm]

@cpper Looks like you get something.
How do you check what you get? qDebug()? You could debug and inspect that QByteArray in the debugger.

[cpper]

@jsulm I used qDebug(). I never used the debugger because I'm always getting "Unknown debugger type "No engine"" error.

[cpper]

Meanwhile I managed to install CDB and debbuged my program.

This is the value of x :

\037\213\010\000\000\000\000\000\000\003í}ÛrÛÆÖæµ\5ï\200aö\226\224\032\231$À3uHQ>ÿv\034'V¶÷Þ¿§\ Ù$\021\201\0007\016:8JÕ\Ìõ¼ÂÜäf^ Wûjü&ó$ó\255î\006Ð \001R\224(\206¶¥JL\022Ýèã:¯Õ«\017þëã\037\036\235üãÍ\023m\024\214míÍÏǯ^<Ò\n\017K¥w\225G¥Òã\223ÇÚß\237\237|ÿJÓ\213eíÄ3\035ß\n,×1íRéÉë\202V\030\005Á¤]*\235\237\237\027Ï+E×\033\226N~*]P[:½,¿>\014\2247\213ý _8zpÀ;¼\030Û\216\177\230Ñ\214ÞjµÄÛ\005Íê\037\026Ʀå¼2/Ý0À»[\007#föñ¹u\020X\201Í\2160²3Ët´>»8(\211G\017\016Æ,01\255`ò\220ý+´Î\016\013=³7b\017{®\023x®]Ðè\013s\002jûâ¡9d\207å\202VÂÀfÞ\233xæpl*/8îCÞVN}v1±<æ+/äµl\215Ñoàºv×ôRíç´,\207ü0¸\234°ÂV<\201\200]\004%ZÏ}\25572=\237\005\207?\237<}ØTZqÌ1Ã\n\210)?

It goes much longer.

[jsulm]

@cpper Is it possible that you got a compressed response?

wtr->setRawHeader("Accept-Encoding","gzip, deflate, sdch");

Can you write the content of the QByteArray into a file and inspect that file?
You could try to open the file with an archiver like WinZip.

[SGaist]

Then you should also check the encoding used

[cpper]

I wrote the bytearray to a file , opened it in winrar and now see the expected output. I was thinking that it might has something to do with compression , but this post here made me think the problem is somewhere else. Thanks very much guys, you saved my day :)

As a fact, I found out that half of my code, the get request after the login post request is useless. I made it that way because chrome shows that this was happening. Here you can see the two requests, as shown in chrome: POST and GET
As you can see the POST request, which is the login one, doesn't have any response, but then there's the GET request in the same location whose response is the page I need. But now I found out that in my program, the reply of the POST request already contains the page, as opposed to chrome, so that I don't need to make another GET request.
I was thinking that maybe the post request automatically made a get redirect in the same location, but then I read that "The Network Access API does not by default follow redirections". I don't quite understand what's happening, but it works, and I'm happy regardless.