On Tue, Jan 7, 2014 at 2:13 PM, Peter Hartmann 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 is data available
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 c
>> 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, download
On segunda-feira, 30 de dezembro de 2013 11:26:48, Mandeep Sandhu wrote:
> > 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.
> 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.
On 30 December 2013 16:07, Mandeep Sandhu 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 can't or intent
>>> 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.
> Escap
On 30 December 2013 11:25, Thiago Macieira wrote:
> 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, b
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 redirecte
>
> 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
__
> 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
>
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 t
On quinta-feira, 26 de dezembro de 2013 14:42:21, Richard Moore wrote:
> On 26 December 2013 13:11, Thiago Macieira
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,
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 Thu, Dec 26, 2013 at 11:06 PM, Richard Moore wrote:
> On 26 December 2013 17:10, Mandeep Sandhu wrote:
>> On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore wrote:
>>> On 26 December 2013 13:11, Thiago Macieira
>>> wrote:
On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wro
On 26 December 2013 17:10, Mandeep Sandhu wrote:
> On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore wrote:
>> On 26 December 2013 13:11, Thiago Macieira wrote:
>>> On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
We could emit download progress for each intermediate req
On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore wrote:
> On 26 December 2013 13:11, Thiago Macieira 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
>
> 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 26 December 2013 13:11, Thiago Macieira 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 values will keep
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 12:45, Mandeep Sandhu 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
>> people want all th
>> 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
> redirecti
On 25 December 2013 07:54, Mandeep Sandhu 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 to the user
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 qt-so
>>
>> 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 t
>> 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 d
On 24 December 2013 07:57, Mandeep Sandhu 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 it makes
> the life
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 tas
28 matches
Mail list logo
