Important: Please read the Qt Code of Conduct -

[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.
    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": 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!

Log in to reply