[SOLVED]QNetworkAccessManager fails to get all headers
-
reply->rawHeaderList() function does not return all the headers in case header fields are more than 9. The Content-Disposition header is missed. The following url contains Content-Disposition header but is skipped, possibly due to presence of P3P header.
http://rs346p6.rapidshare.com/cgi-bin/rsapi.cgi?sub=download&fileid=281856921&filename=CA-14_Food___Beverage.rar&dlauth=0123456789
You can verify it in firefox. LiveHttp Headers addon displays a content-disposition header in the response sent by server, but is missed by QNetworkReply.
-
Uh, that sounds like a very serious bug. If you have a reproducible testcase, please submit a bug on the bugtracker.
-
Just ran synthetic example. Everything's works as expected:
@("X-Powered-By", "X-Header-1", "X-Header-2", "X-Header-3", "X-Header-4", "X-Header-5", "X-Header-6", "X-Header-7", "X-Header-8", "X-Header-9", "X-Header-10", "X-Header-11", "X-Header-12", "X-Header-13", "X-Header-14", "X-Header-15", "Content-Type", "Content-Length", "Date", "Connection")@rawHeaderList() of QNetworkReply for rapidshare url is:
@("Date", "Connection", "Content-Type", "Accept-Ranges", "Content-Disposition", "Content-Length")@
-
This is my output:
@<9 items> QList<QByteArray>
[0] "P3P" QByteArray
[1] "Date" QByteArray
[2] "Accept-Ranges" QByteArray
[3] "Content-Type" QByteArray
[4] "Content-Length" QByteArray
[5] "X-Cache" QByteArray
[6] "X-Cache-Lookup" QByteArray
[7] "Via" QByteArray
[8] "Proxy-Connection" QByteArray@I use a proxy server, so my request/response contains more headers.
-
Can you try WITHOUT using a proxy server? Does a sniffer show that QNAM is actually receiving those headers?
-
Here is output of Live HTTP headers addon:
@HTTP/1.1 200 OK
Date: Sun, 07 Oct 2012 14:27:55 GMT
Connection: close
Content-Type: application/octet-stream
Accept-Ranges: bytes
Content-Disposition: attachment; filename="CA-14_Food___Beverage.rar"
Content-Length: 171022670
@
Here is the output of QNAM without proxy:
@<6 items> QList<QByteArray>
[0] "P3P" QByteArray
[1] "Date" QByteArray
[2] "Connection" QByteArray
[3] "Accept-Ranges" QByteArray
[4] "Content-Type" QByteArray
[5] "Content-Length" QByteArray@
I am using HEAD instead of GET, could that be the reason.
-
I'm fairly sure that the HTTP specification forbits such behaviour. Can you try with a GET? Can you also try to fake the User-Agent?
-
Executing HEAD on that URL gives me:
("Date", "Connection", "Content-Type", "Accept-Ranges", "Content-Length")
and GET:
("Date", "Connection", "Content-Type", "Accept-Ranges", "Content-Disposition", "Content-Length")
No proxy involved. It is also in agreement with the headers returned using "curl --head {URL}" and "curl -D - -range 0-499 -o/dev/null {URL}" (fetches first 500 bytes).Content-Disposition is optional ("RFC 2616":http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1) and only meaningful in the event the content is actually being sent. The content is not sent in response to a HEAD request, so the service has opted not to send the header.
As for the initial claim that more than ten headers breaks Qt handling, the headers for a GET on this thread are:
("Last-Modified", "Pragma", "Vary", "Content-Encoding", "Content-Type", "Cache-Control", "Accept-Ranges", "Date", "X-Varnish", "Age", "Via", "Connection")
12 in total and returned just fine by Qt.
-
Thanks it was really a helpful description!
