[Development] Proposal for allowing handling of HTTP redirects in QNAM

Mandeep Sandhu mandeepsandhu.chd at gmail.com
Tue Jan 7 10:44:05 CET 2014


On Tue, Jan 7, 2014 at 2:13 PM, Peter Hartmann <phartmann at 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 is data available) and do it only once we
>> arrive at the final url (though we continue to read the full response
>> of each redirect). So the final signals will reflect the data as if
>> the request was made directly to that url. Is that your understanding
>> too?
>
>
> Sounds good to me as well; while technically a site often sends a body with
> a redirect, in practice all the information needed is stored in the
> "Location:" header. So we could just discard the body for redirecting
> replies in the "follow automatic redirects" case. If an app does want to use
> the body, it could still handle redirects itself...

Great!

I just checked with Nginx's default configuration a few days back and
it too sent a samll 'body' in the redirect reply (it just says where
the page is being redirected to). Though I think thats for helping
clients, that _don't_ support redirects, show some message to a user.
In our case, it'll be pretty redundant.

-mandeep

>
> Peter
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>



More information about the Development mailing list