[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 #19 from adawit at kde.org  2010-03-22 15:36:07 PST ---
(In reply to comment #16)
> (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.

Well that is fine by me... The issue can indeed be solved through documenting
that unsupportedContent signal is emitted whenever a "content-disposition"
header is encountered as well...

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