On 12/31/2013 06:35 AM, Mandeep Sandhu wrote:
Okay. I think Richard also suggested the same approach, i.e as long as
we are being redirected, we don't emit the downloadProgress (and other
signals indicating there is data available) and do it only once we
arrive at the final url (though we
On Tue, Jan 7, 2014 at 2:13 PM, Peter Hartmann phartm...@blackberry.com wrote:
On 12/31/2013 06:35 AM, Mandeep Sandhu wrote:
Okay. I think Richard also suggested the same approach, i.e as long as
we are being redirected, we don't emit the downloadProgress (and other
signals indicating there
On segunda-feira, 30 de dezembro de 2013 11:23:29, Mandeep Sandhu wrote:
Maybe rare for URL shorteners. Internal redirects inside a web site or
group of sites are a different matter: call me an old-grumpy-Mosaic-user
if you like, but I usually add a body of the if you are not redirected
So I guess having body in the 3xx response will not be all that unusual.
It will be.
Actually, it's extremely common - here's a default apache 301 for example:
monster:/home/rich/src/wireshark # telnet xmelegance.org 80
Trying 80.68.89.8...
Connected to xmelegance.org.
Escape character
On 30 December 2013 16:07, Mandeep Sandhu mandeepsandhu@gmail.com wrote:
So I guess having body in the 3xx response will not be all that unusual.
It will be.
Actually, it's extremely common - here's a default apache 301 for example:
[snip]
I guess the body is provided for clients who
Since we know immediately that we're being redirected we can simply
wait until we get a non-redirecting response before we start emitting
the progress signals. We just need to (internally) ensure that we've
read the body from the redirect response, the user of QNAM doesn't
need to care.
Even so, the body content might still be of different sizes, so the
total bytes will have to change across redirects. This to me doesn't
look very consistent.
I say once again: the downloadProgress includes *only* the body, not a single
byte of header or of overhead. Also, downloadProgress()
Maybe rare for URL shorteners. Internal redirects inside a web site or group
of sites are a different matter: call me an old-grumpy-Mosaic-user if you
like, but I usually add a body of the if you are not redirected
automatically click here -type when I program redirects, I usually even
No, it doesn't. It includes only data. The HTTP headers are metadata, so they
don't count.
Even so, the body content might still be of different sizes, so the
total bytes will have to change across redirects. This to me doesn't
look very consistent.
-mandeep
On Friday 27 December 2013, Mandeep Sandhu wrote:
Got it. If there's some content in the 'body' part of the response and
it points to the same server which sent a redirect, then we could
reuse the existing connection.
Though it might be a rare case where the redirects will have a 'body'
On quinta-feira, 26 de dezembro de 2013 14:42:21, Richard Moore wrote:
On 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com
wrote:
There is no downloadProgress for any intermediate requests. We know that
we're redirecting before we get the first byte of data out of the
On quinta-feira, 26 de dezembro de 2013 22:39:03, Mandeep Sandhu wrote:
There is no downloadProgress for any intermediate requests. We know that
we're redirecting before we get the first byte of data out of the server.
At that point, we can abandon the QHttpNetworkReply and move on to the
On Thu, Dec 26, 2013 at 11:06 PM, Richard Moore r...@kde.org wrote:
On 26 December 2013 17:10, Mandeep Sandhu mandeepsandhu@gmail.com wrote:
On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore r...@kde.org wrote:
On 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com
wrote:
On
On 25 December 2013 07:54, Mandeep Sandhu mandeepsandhu@gmail.com wrote:
3. QNetworkReply stores both, the original as well as the final url.
What about the intermediate ones in a chain of redirects?
Another question that springs to mind is what should the QNetworkReply
object returned
Your thoughts?
The download progress signal will have to be emitted for the
intermediate requests. Things like operation() and url() are stored in
the request object which can't be changed by the QNAM at all. If
people want all the details then they must implement their own
redirection
On 26 December 2013 12:45, Mandeep Sandhu mandeepsandhu@gmail.com wrote:
Your thoughts?
The download progress signal will have to be emitted for the
intermediate requests. Things like operation() and url() are stored in
the request object which can't be changed by the QNAM at all. If
On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
We could emit download progress for each intermediate request, but
won't that look strange to a user as the bytes received _possibly_
bytes total values will keep changing across these requests? Or is
that acceptable
On 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com wrote:
On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
We could emit download progress for each intermediate request, but
won't that look strange to a user as the bytes received _possibly_
bytes total
There is no downloadProgress for any intermediate requests. We know that we're
redirecting before we get the first byte of data out of the server. At that
point, we can abandon the QHttpNetworkReply and move on to the next already.
The downloadProgress signal gives info about the received
On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore r...@kde.org wrote:
On 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com wrote:
On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
We could emit download progress for each intermediate request, but
won't that
On 26 December 2013 17:10, Mandeep Sandhu mandeepsandhu@gmail.com wrote:
On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore r...@kde.org wrote:
On 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com wrote:
On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
We
On quarta-feira, 25 de dezembro de 2013 13:24:43, Mandeep Sandhu wrote:
If this gets unnecessarily complex to be done from within the QNAM
framework, maybe we can have some sort of a 'wrapper' class handling
redirects using QNR's public APIs. We could possibly keep such a class
in the
On 24 December 2013 07:57, Mandeep Sandhu mandeepsandhu@gmail.com wrote:
Hi All,
Few days back I stumbled upon this task:
https://bugreports.qt-project.org/browse/QTBUG-8232
QNetworkAccessManager should support redirection
I think this is a useful feature that can be added to QNAM as
2. New redirected(QUrl) signal to be emitted in case auto-redirects
are enabled and a redirection occurs.
This interface wouldn't be enough to let you distinguish between the
different types of redirect, though tbh I'm not sure that matters.
By different types, I guess you mean the different
3. QNetworkReply stores both, the original as well as the final url.
What about the intermediate ones in a chain of redirects?
Another question that springs to mind is what should the QNetworkReply
object returned to the user reflect while the redirects are going on?
Eg: What should the
Hi All,
Few days back I stumbled upon this task:
https://bugreports.qt-project.org/browse/QTBUG-8232
QNetworkAccessManager should support redirection
I think this is a useful feature that can be added to QNAM as it makes
the life of a developer easy.
I went through all the comments in the task
26 matches
Mail list logo
