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

[Mandeep Sandhu]

>> 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 status codes
returned, like 301 or 302 etc?

We could have status code emitted as part of the signal. But as you
mentioned below, keeping the API simple, just the redirected URL
should be good enough to begin with.

>
>>
>> 3. QNetworkReply stores both, the original as well as the final url.
>
> What about the intermediate ones in a chain of redirects?

The user can track/inspect intermediate urls via the "redirected(QUrl)" signal.

>> 5. Allow a way to specify which protocols are allowed on redirects.
>> Eg: curl by default does not redirect to "file" and "scp" protocols.
>
> I don't think that should be offered. We pretty much concluded that
> same-protocol redirects were okay, as were http -> https but others
> were a mine field. https->http is one that I'm still unsure of since
> it's one we see in real life, but has potential risks. If an app needs
> detailed control (eg. as a browser does) then it should implement the
> handling itself. QNAM should only handle the simple case.

Ok. Maybe the secure to unsecure redirect can be controlled by a flag?

>>
>> 6. Allow a way to specify redirect behaviour for POST requests. Eg: if
>> a 301 is returned, the RFC states that the user agent MUST NOT change
>> it to a GET request automatically.
>
> IIRC the RFC is wrong or at least incomplete here and does not
> describe actual behaviour of browsers. See
> http://en.wikipedia.org/wiki/Post/Redirect/Get for more details.

This part is a bit grey as browsers don't seem to follow the
recommended behaviour. The RFC actually mentions this deviation by
browsers in the "Note":
http://www.ietf.org/rfc/rfc2616.txt (Sec 10.3.2).

We can follow the behaviour expected of a 303 response where the POST
req is converted to a GET as thats what most browsers seem to be doing
too.

>> I was wondering if a patch for it will be acceptable?
>
> Sure, however it's quite involved. From inside the http backend you
> need to start a new request meaning there's not a 1:1 mapping between
> user requests and the internal ones. This is similar to what happens
> with proxy auth etc. so you should look at the code that implements
> that for inspiration.

Thanks for this pointer. I'll have a look at the proxy code to see how
involved the changes are going to be.

Regards,
-mandeep

>
> Cheers
>
> Rich.