content-disposition in HTTP headers

[David Faure]

On Monday 13 March 2006 16:45, Allan Sandfeld Jensen wrote:
> Ok. Further testing showed that content-disposition: attachment is indeed not 
> honoured, but my patch didn't fix it either. I've reopened bug #31662 
> (http://bugs.kde.org/show_bug.cgi?id=31662)
> 
> The attached patch is updated and fixes the bug as far as I can tell, and 
> should be safe for KDE 3.5.2. 

Thanks for the patch. Looks fine over all.
I'm not sure I understand this part though:

+    if (!tryEmbed) // try now
+        m_bFinished = m_pMainWindow->openView( mimeType, m_strURL, m_pView, m_req );
To me tryEmbed==false means "don't try embedding", so why is this trying to embed? ;)
This is for the case where the server asks to save, and the user chose "Open" instead?
In that case I think it should be done a bit earlier, like

--- konq_run.cc (revision 503943)
+++ konq_run.cc (working copy)
@@ -107,6 +107,8 @@ void KonqRun::foundMimeType( const QStri
     if ( res == KParts::BrowserRun::Delayed )
       return;
     m_bFinished = ( res == KParts::BrowserRun::Handled );
+    if ( !m_bFinished && !tryEmbed )
+        m_bFinished = m_pMainWindow->openView( mimeType, m_strURL, m_pView, m_req );
   }

   // make Konqueror think there was an error, in order to stop the spinning wheel


Smaller comments:

+        bool serverSuggestsSave() const { return contentDisposition() == "attachment"; };
should be
+        bool serverSuggestsSave() const { return contentDisposition() == QString::fromLatin1("attachment"); }
in case someone compiles with the no-ascii-cast flag (and trailing ";" was removed too).

I'm happy to see that the "reserved for later use" int flags in BrowserRun::askEmbedOrSave
was useful; don't forget to adjust the API docs for it though.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).