[rekonq] KDE/kdelibs/kdewebkit

[Dawit A]

On Wednesday, May 19, 2010 05:13:37 Andrea Diamantini wrote:
> On Wednesday 19 May 2010 02:08:45 Dawit Alemayehu wrote:
> > SVN commit 1128338 by adawit:
> > 
> > - Added a slot that properly handles the downloading of replies that
> > might contain "content-disposition" headers.
> > 
> >   Note this new API was added this late in anticipation of fixing a
> > 
> > critical issue that is awaiting a pending patch upstream in QtWebKit. See
> > https://bugs.webkit.org/show_bug.cgi?id=37880
> 
> Many thanks for, Dawit.
> If I understand things well, this new code works now as the previous one
>
> and will start working "better" (read, consider "content-disposition"
> headers) when your patch to QtWebKit will be applied (so, QtWebKit 2.1)
> 
> Is this correct?

Not entirely... 

#1. Yes, this new function, downloadResponse, is better in the sense that it 
handles content-disposition whereas downloadRequest (I assume that is what you 
mean by the previous one) does not, but these two slots have different 
purposes. The former was added to allow you to connect 
QWebPage::downloadRequested signal where as the later is added to allow you to 
connect QWebPage::unsupportedContent signal.

#2. My content-disposition patch for upstream QtWebKit was already accepted 
and committed upstream a while back and it will be in QtWebKit 2.0. If you 
have forwarding of unsupported content enabled, then the unsupported content 
signal will be emitted when the user clicks on a link for which the server 
responds with a "Content-Disposition" in its header. And yes the new slot as 
stated above makes it a lot easier for you to support this by handling 
everything.

However, that was not what I meant by the pending critical issue awaiting the 
upstream fix. No that is a separate issue outlined in the bug report mentioned 
above. Actually it is an issue first raised to me by Ronny who works on reKonq 
as well. The issue is if you left click a link to download it or press a 
submit button that results in unsupportedContent signal, we have to abort the 
original request and redo it again if the content is to be saved to disk or 
even worse opened with another application. Unfortunately this is not always 
possible. For example, the unsupportedContent signal might be a result of 
content returned during a POST operation or the webserver explicitly forbids 
immediate re-downloading of the same file by the same client within certain 
duration. 

That was the issue I was speaking of. Once the patch upstream is committed the 
new downloadResponse slot will also be modified to handle/deal with this issue.

Regards,
Dawit A.