[Webkit-unassigned] [Bug 36395] [Qt] Patch to add support for Content-Disposition...

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=36395





--- Comment #16 from Simon Hausmann <hausmann at webkit.org>  2010-03-22 14:49:29 PST ---
(In reply to comment #9)
> (In reply to comment #3)
> > From an API perspective the first solution sounds better to me than the second
> > one, which I feel may be confusing. Is it just me? :)
> 
> The problem with the first solution is that QWebPage::unsupportedContent is not
> emitted by default unless the client application explicitly enables it by
> invoking QWebPage::setForwardUnsupportedContent. To me this seems to be an 
> impedement because the "Content-Disposition" header is a common way web servers
> indicate that a resource is supposed to be downloaded and not rendered by
> default. 
> As such, the handling of request that contain the "content-disposition" header
> should not be left up to a signal that is only emitted whenever a client
> application explicitly enables it. Furthermore, client applications are likely
> to handle unsupported content and download requests differently and having a
> single signal to deal with these two different issues seems to go against
> standard Qt API practise, no ? Anyhow, regardless of the chosen approach, the
> signal that gets emitted as result of encountering this header should IMHO need
> to be ON by default.

Either approach requires changes in the application.

The approach of adding an overloaded signal requires us to do _magic_ in
WebKit, i.e. detect if someone is connected to the signal and otherwise
_cancel_ the QNetworkReply's download. We had _exactly_ that problem with the
unsupportedContent signal during the API design and decided against magic, as
it tends to get in the programmer's way.

So I'm in favour of a solution that is consistent to the existing API, which is
why I like your first patch. It can be documented - in the class or module
overview - when unsupportedContent() is emitted.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.