Version: Unbekannt (using KDE 3.1.1) Installed from: (testing/unstable) Compiler: gcc version 3.2.3 20030309 (Debian prerelease) OS: Linux (i686) release 2.4.21-rc1 Although other (closed) bug reports (like #23143) indicate that this problem was fixed long ago, it still doesn't work with KDE 3.1.1. A PHP-Script of mine sends a picture with the Content-disposition: filename="file.jpeg" header (the picture is part of an HTML page). When I right-click on the picture and select "Save Picture As..." then konqueror suggests the name of the PHP script instead of file.jpeg as the filename. Works with Mozilla.
Hello, Do you by any change use the kget download manager ?
Subject: Re: konqueror ignores Content-disposition: filename="xxx" header On Fri, 25 Apr 2003, Dawit Alemayehu wrote: > Do you by any change use the kget download manager ? No, it's not even installed. I view a HTML page with an embedded image. I right-click on the image and select "Safe Image As...". Then konqueror suggests the filename from the PHP-Script which served the image instead of the filename given in the HTTP-Header for the image. Walter
I have same problem with KDE 3.1.3 installed from SuSE RPM's.
*** Bug 68789 has been marked as a duplicate of this bug. ***
Is there an example link you can give ? I still am unable to duplicate this. With the links at kde-look.org, the current versions of KDE behave in similar manner as Mozilla.
Also, if you simply left click on the image, is the right name shown in the location bar ?
If I left click on the image nothing happens (it's not a link). If I right click the contect menu is displayed. There is an entry to view only the image in the menu. This entry is called (german translation) Bild betrachten (picture.php...c6a823a7b7) picture.php is the script that delivers the image. The hex code is the end of the picture url. If I select this entry from the menu the image is downloaded, saved to a temporary filename and displayed with an external viewer. If I right click on the image and select save image then a save dialog is displayed with "picture.php" given as the suggested filename.
Created attachment 3443 [details] A PHP script demonstrating the problem (WARNING! Don't put on public web server, will deliver any local file)
Created attachment 3444 [details] An HTML file with a picture included. View this with konqueror. It only works if the image is correctly shown. See the comment above for installation instructions.
Created attachment 3445 [details] A random image file. Put it in the same directory as the other two files.
I added a test case consisting of three files (picture.html, picture.php, image.jpg). Copy to a local directory. Set your webserver so that you can access the directory and php scripts will be executed. View picture.html with konqueror. It includes a picture delivered by the php file. Right-click on the picture and select "save as". Konqueror will suggest "picture.php" as the filename. It should suggest "image.jpg" as the filename. NOTE: The php file will deliver any local file. Make sure you delete it after use.
Subject: / CVS commit by adawit: - Fix BR#57590: konqueror ignores Content-disposition: filename="xxx" header. Reviewed by Waldo and the release dude :) CCMAIL:57590-done@bugs.kde.org M +11 -5 kdebase/konqueror/konq_mainwindow.cc 1.1264 M +4 -1 kdelibs/kparts/browserrun.h 1.12 --- kdelibs/kparts/browserrun.h #1.11:1.12 @@ -77,4 +77,7 @@ namespace KParts { bool hideErrorDialog() const; + // Suggested filename given by the server (e.g. HTTP content-disposition) + QString suggestedFilename() const { return m_suggestedFilename; } + enum AskSaveResult { Save, Open, Cancel }; /** --- kdebase/konqueror/konq_mainwindow.cc #1.1263:1.1264 @@ -801,6 +801,12 @@ bool KonqMainWindow::openView( QString s // So we ask the user, instead, except in some very well-known cases. if ( !forceAutoEmbed && !KProtocolInfo::supportsWriting( url ) && url.protocol() != "about" ) { + QString suggestedFilename; + + KonqRun* run = childView->run(); + if (run) + suggestedFilename = run->suggestedFilename(); + KParts::BrowserRun::AskSaveResult res = KParts::BrowserRun::askEmbedOrSave( - url, serviceType/*, suggestedFilename TODO - get from KonqRun! */ ); + url, serviceType, suggestedFilename ); if ( res == KParts::BrowserRun::Open ) forceAutoEmbed = true; @@ -808,5 +814,5 @@ bool KonqMainWindow::openView( QString s return true; // handled, don't do anything else else { // Save - KParts::BrowserRun::simpleSave( url, QString::null /* suggestedFilename TODO */, this ); + KParts::BrowserRun::simpleSave( url, suggestedFilename, this ); return true; // handled } @@ -2219,5 +2225,5 @@ void KonqMainWindow::updateLocalPropsAct } -void KonqMainWindow::slotURLEntered( const QString &text, ButtonState state ) +void KonqMainWindow::slotURLEntered( const QString &text, int state ) { if ( m_bURLEnterLock || text.isEmpty() ) @@ -2676,6 +2682,6 @@ void KonqMainWindow::initCombo() m_combo->init( s_pCompletion ); - connect( m_combo, SIGNAL(activated(const QString&,ButtonState)), - this, SLOT(slotURLEntered(const QString&,ButtonState)) ); + connect( m_combo, SIGNAL(activated(const QString&,int)), + this, SLOT(slotURLEntered(const QString&,int)) ); m_pURLCompletion = new KURLCompletion();
*** Bug 72194 has been marked as a duplicate of this bug. ***
Where this is resolved? Yesterday I installed brand fresh 3.2 release and still same bug exists!!!
Subject: Re: konqueror ignores Content-disposition: filename="xxx" header Any test URL where you see the problem?
I can also confirm that it's still broken in 3.2.0. The attachments below demonstrate the problem. To test, open the attachment below labeled "An HTML file with a picture included...". Right click on the (broken) image and click "Save image as..." You'll be presented with a file dialog suggesting the filename "picture.php". It should correctly be "image.jpg" as directed by the "filename=" directive.
@Fred: If the image icon is broken then you didn't install the test case correctly. This could be the reason for the wrong filename. You need to fix this first before you can see whether the bug is fixed or not.
Comment on attachment 3444 [details] An HTML file with a picture included. View this with konqueror. It only works if the image is correctly shown. See the comment above for installation instructions. <HTML><HEAD/><BODY> <IMG src="picture.php?mimetype=image/jpeg&filename=image.jpg"/> <P> If you cannot see the picture above, then this testcase is not correctly installed. Please read the corresponding comment in bug #3444! </BODY></HTML>
Comment on attachment 3444 [details] An HTML file with a picture included. View this with konqueror. It only works if the image is correctly shown. See the comment above for installation instructions. ><HTML><HEAD/><BODY> ><IMG src="picture.php?mimetype=image/jpeg&filename=image.jpg"/> ></BODY></HTML>
Thanks for you input Walter. I took you advice and copied all three attachments locally for a more valid test. Same result. However, the same test scenario works correctly in both Mozilla and IE. Hence, all the pieces necessary to validate this problem are included in this bug report. Bottom line is that it still fails in Konq, but not in IE or Mozilla.
that test case doesn't work for me as mod_php doesn't allow readfile
I created one testcase. I put this up on http://www.zone.ee/raudpats/57590_testcase.php There is also given PHP script what I use to output image. And as I wrote there this example works with all other browers I tried and not with Konqueror.
Andres... Thanks for providing a useful testcase. Walter, Stephan... Can we re-open this bug then?
yep
Actually, the subject of this bug report is misleading. It is not konqueror that ignores it. It is KHTML itself. Poor konqueror it cannot catch a break... That too should be fixed shortly and both the LMB (links) and RMB (non-link images) clicks should offer the "suggested filename".
*** Bug 76369 has been marked as a duplicate of this bug. ***
Still broke in kde3.2.1.
Simply click on the PHP attachment to this bug. The file dialog prompts with the suggestion "attachment.cgi".
Fred: Clicking on the PHP attachment is not the correct way to verify if the bug is still there (bugs.kde.org doesn't send a Content-disposition: for the attachment). Please use Andreas Kaerner's test case: http://www.zone.ee/raudpats/57590_testcase.php
You're right. However, Andreas' test case still fails. Problem still exists in 3.2.1. :)
*** Bug 77473 has been marked as a duplicate of this bug. ***
This may be related to bug 79597
*** Bug 79597 has been marked as a duplicate of this bug. ***
Hello, The bug in KHTML that caused this issue has been fixed. However, one tricky issue remains unresolved. If the page you are viewing is stored in kio_http's cache, the suggested filename will not be available because kio_http does not store extraneous meta-data such as content-disposition in the cache. As such any page fetched from the cache will incorrectly show the filename of the resource rather than the suggested filename. Anyways, those running KDE from cvs HEAD can give the fix a try...
I guess the fix didn't make it into 3.2.2. I cleared and disabled cache then re-tried Andres test case (http://www.zone.ee/raudpats/57590_testcase.php) above. Still broke. :(
Looks like this has lost the attention of the developers. It's a rather serious bug (IMO) and is still broke in kde3.3-beta1.
No, we did not ignore it. It was fixed with the exception of the caching issue and the fix was also tested with the example posted above which unfortunately does not work anymore. The only time the suggested filename should be ignored is when the page is retrieved from cache. That is why I left the bug report open. Do you have another test case or site where this does not work ?
I appreciate your response Dawit and also knowing that the problem isn't being ignored because it is (was) a *serious* bug IMO. Apparently, even though I've deleted/disabled cache I am still receiving the error when using the aforementioned page. After moving the same code to another site and retesting it there the bug does, in fact, appear to have been fixed. My apologies and many thanks for your indulgence. :)
This still seems to be very broken in HEAD. Even with uncached pages I still see this bug.
George, Care to give an example site where it does not work when caching is not enabled ? On Monday 25 October 2004 04:31, George Staikos wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=57590 > > > > > ------- Additional Comments From staikos kde org 2004-10-25 10:31 ------- > This still seems to be very broken in HEAD. Even with uncached pages I > still see this bug. _______________________________________________ > Konq-bugs mailing list > Konq-bugs@mail.kde.org > https://mail.kde.org/mailman/listinfo/konq-bugs
CVS commit by staikos: Use the HTTP suggested filename for images, in particular for the View Image menu text and the Save Image As suggestion. Thanks to David Faure for basically writing the patch in English first, and reviewing after. :) BUG: 57590 M +7 -0 ChangeLog 1.311 M +13 -2 khtml_ext.cpp 1.103 M +2 -1 rendering/render_image.h 1.53 --- kdelibs/khtml/ChangeLog #1.310:1.311 @@ -1,2 +1,9 @@ +2004-10-25 George Staikos <staikos@kde.org> + + * rendering/render_image.cpp: Pass through the CachedObject so we can + use the suggested filename possibly provided by the HTTP headers. + + * khtml_ext.cpp: Make use of the suggested filename for images. + 2004-10-24 David Faure <faure@kde.org> --- kdelibs/khtml/khtml_ext.cpp #1.102:1.103 @@ -31,4 +31,7 @@ #include "khtml_pagecache.h" #include "rendering/render_form.h" +#include "rendering/render_image.h" +#include "html/html_imageimpl.h" +#include "misc/loader.h" #include "dom/html_form.h" #include "dom/html_image.h" @@ -343,4 +346,5 @@ public: KURL m_url; KURL m_imageURL; + QString m_suggestedFilename; }; @@ -362,4 +366,11 @@ KHTMLPopupGUIClient::KHTMLPopupGUIClient (e.elementId() == ID_INPUT && !static_cast<DOM::HTMLInputElement>(e).src().isEmpty()))) { + if (e.elementId() == ID_IMG) { + DOM::HTMLImageElementImpl *ie = static_cast<DOM::HTMLImageElementImpl*>(e.handle()); + khtml::RenderImage *ri = dynamic_cast<khtml::RenderImage*>(ie->renderer()); + if (ri && ri->contentObject()) { + d->m_suggestedFilename = static_cast<khtml::CachedImage*>(ri->contentObject())->suggestedFilename(); + } + } isImage=true; } @@ -488,5 +499,5 @@ KHTMLPopupGUIClient::KHTMLPopupGUIClient actionCollection(), "copyimagelocation" ); QString name = KStringHandler::csqueeze(d->m_imageURL.fileName()+d->m_imageURL.query(), 25); - new KAction( i18n( "View Image (%1)" ).arg(name.replace("&", "&&")), 0, this, SLOT( slotViewImage() ), + new KAction( i18n( "View Image (%1)" ).arg(d->m_suggestedFilename.isEmpty() ? name.replace("&", "&&") : d->m_suggestedFilename.replace("&", "&&")), 0, this, SLOT( slotViewImage() ), actionCollection(), "viewimage" ); } @@ -530,5 +541,5 @@ void KHTMLPopupGUIClient::slotSaveImageA KIO::MetaData metaData; metaData["referrer"] = d->m_khtml->referrer(); - saveURL( d->m_khtml->widget(), i18n( "Save Image As" ), d->m_imageURL, metaData ); + saveURL( d->m_khtml->widget(), i18n( "Save Image As" ), d->m_imageURL, metaData, QString::null, 0, d->m_suggestedFilename ); } --- kdelibs/khtml/rendering/render_image.h #1.52:1.53 @@ -58,4 +58,5 @@ public: bool complete() const; + CachedObject *contentObject() { return image; } void setContentObject( CachedObject* );
On Monday 25 October 2004 08:14, you wrote: > Care to give an example site where it does not work when caching is not > enabled ? I just fixed it a few minutes ago. It was easy to reproduce. Make a PHP script like this: header("Content-Disposition: attachment; filename=foo.jpg"); .... imagejpg($im); Then RMB over the image and Save Image As.... The filename will be the name of the PHP script.
Ok, if it's in the cache it won't be "fixed", but any site that feeds unknown files and leaves caching on is pretty broken IMHO. The fix for files retrieved from the cache is to store the content-disposition metaData in the cache.
George's patch is refering to images only. Is this only missing generalization in naming or will it not be working on other file types?
Well the only case I could see was KHTMLImage - pictures embedded in pages. Do you have another case? I think the others already worked...
I had a similar problem with an inlined zip-archive. Now I'm not quite sure any more, if this is really related to bug 57590. I managed to boil it down to a simple test case, maybe anyone can test it against a patched khtml. Unfortunately I'm currently not able to compile kde. The test case consist of a php-script tc.php and a frameset index.html. The script simply zips itself and sends the result as an inlined file to the browser which should should ask to store the file or open it with some zip-application. Konqueror instead displays the zipped contents in its browser window. Other browsers behave correctly. The bug appears only when the script is embedded in a frame and called by the post method. In order to apply the testcase you have to install the two files so that they can be called via a php enabled web server. If you load the file index.html (the frameset), the bug should appear. If you call tc.php directly, everythig should work correctly. --8<- index.html ----- <html> <head> <title>Testcase for Bug 57590 with frames</title> </head> <frameset> <frame src="tc.php"></frame> </frameset> </html> -->8------ --8<- tc.php ----- <? if ( $HTTP_POST_VARS["ACTION"] == "Load" ) { $cmd = "zip -l - tc.php"; $fpf = popen( "$cmd", "r" ); header("Content-Type:application/x-zip"); header("Content-Disposition:inline;filename=\"archiv.zip\""); fpassthru($fpf); exit; } ?> <html> <head> <title>Testcase for Bug 57590</title> </head> <body> <h1>Testcase for Bug 57590:</h1> <p> by pressing the load button, the file "tc.php" will be zipped to stdout and send to the browser. The browser should ask to store the file or open it with some zip-application. </p> <p> Konqueror displays the zipped contents in its browser window. </p> <form action="" method=post> <input type=submit name="ACTION" value="Load"> </form> </body> </html> -->8------ Created an attachment (id=8051) index-1.html Created an attachment (id=8052) tc.php
i have a special case of this as well (using kde-3.3.2) good news: when i click on 'download' of a attachment in squirrelmail i get the suggested name bad news: when dragging the link unto the desktop it gets the scripts name. mail me to get a squirrelmail account
*** Bug 124815 has been marked as a duplicate of this bug. ***
*** Bug 125302 has been marked as a duplicate of this bug. ***
As the two bugs above been marked as duplicate of this one I'd like to add that the problem seems to be also somewhere between konqueror (kio_http) and KGet. When kget is active and I click on script with proper "Content-disposition" the the window with "Save as..., Open, Cancel" shows the name suggested by "Content-disposition filename" but after clicking "Save as..." in kget save dialog only the script name (get.php etc.) is shown. With kget turned off after "Save as..." proper filename is shown in save file dialog. When I select "Save link as..." from RMB menu I always get script name (which is quite understandable as the name is not known yet (but it might be ;))) both with and without kget. I'm not really sure when this changed - I'm sure that some two or three versions (as I install every stable and most betas) it worked OK - name from "Content-disposition" was properly passed to kget (then somewhere in 3.5.0 this bug (http://bugs.kde.org/show_bug.cgi?id=120228) was introduced but after patching it worked fine, and now in 3.5.2 something is definitely wrong again).
I'm seeing something related to this, on some links (in particular, attachments to TopCoder development forums). When KGet is enabled, I'm presented with an Open/Save As.../Cancel dialog and if I choose 'Save As...' KGet does not ask for a filename and saves the file under the name of the script (e.g. attachment.cgi) in my home directory. I do not have KGet configured to auto-download anything -- it is always supposed to ask for a directory (at least) to save to. When KGet is disabled, a simple left-click will attempt to open the file inside konqueror (this may depend on the file type, generally I'm downloading PDFs or ZIPs). Right-clicking and choosing 'Save Link As...' allows me to choose a location to save the file, but suggests the name of the script instead of the filename served in the Content-Disposition header. I'm using 3.5.4 on Gentoo/~amd64. Also, I disagree with the assertion that such a script should always disable caching. HTTP caching uses the whole URL (including the query string) and the script may know that it is acceptable to cache a particular (or possibly all) files served by it, in particular that it will generate the same data for the same query string within a sufficiently small period of time. The content-disposition header should somehow be saved by KDE's caching mechanism.
*** Bug 110648 has been marked as a duplicate of this bug. ***
SVN commit 709862 by carewolf: Cache content-disposition and content-language. BUG: 57590 M +1 -1 kio/kio/http_slave_defaults.h M +75 -38 kioslave/http/http.cpp M +3 -0 kioslave/http/http.h --- trunk/KDE/kdelibs/kio/kio/http_slave_defaults.h #709861:709862 @@ -28,7 +28,7 @@ #define DEFAULT_CACHE_EXPIRE 3*60 // 3 MINS #define DEFAULT_CLEAN_CACHE_INTERVAL 30*60 // 30 MINS #define DEFAULT_CACHE_CONTROL KIO::CC_Refresh // Verify with remote -#define CACHE_REVISION "7\n" // Cache version +#define CACHE_REVISION "8\n" // Cache version // DEFAULT USER AGENT KEY - ENABLES OS NAME #define DEFAULT_USER_AGENT_KEYS "o" // Show OS --- trunk/KDE/kdelibs/kioslave/http/http.cpp #709861:709862 @@ -2625,17 +2625,40 @@ kDebug(7113) << "(" << m_pid << ") HTTPProtocol::readHeader: cached " << "data mimetype: " << m_strMimeType << endl; - if (!gzgets(m_request.fcache, buffer, 4096) ) - { - // Error, delete cache entry - kDebug(7113) << "(" << m_pid << ") HTTPProtocol::readHeader: " - << "Could not access cached data! " << endl; - error( ERR_CONNECTION_BROKEN, m_state.hostname ); - return false; + // read optional http-headers + while(true) { + if (!gzgets(m_request.fcache, buffer, 4096) ) + { + // Error, delete cache entry + kDebug(7113) << "(" << m_pid << ") HTTPProtocol::readHeader: " + << "Could not access cached data! " << endl; + error( ERR_CONNECTION_BROKEN, m_state.hostname ); + return false; + } + QString header = QString::fromUtf8( buffer).trimmed().toLower(); + if (header.isEmpty()) break; + if (header.startsWith("content-type-charset: ")) { + QString value = header.mid(22); + m_request.strCharset = value; + setMetaData("charset", value); + } else + if (header.startsWith("content-language: ")) { + QString value = header.mid(18); + m_request.strLanguage = value; + setMetaData("content-language", value); + } else + if (header.startsWith("content-disposition-type: ")) { + QString value = header.mid(26); + m_request.strDisposition = value; + setMetaData("content-disposition-type", value); + } else + if (header.startsWith("content-disposition-filename: ")) { + QString value = header.mid(30); + m_request.strFilename = value; + setMetaData("content-disposition-filename", value); + } } - m_request.strCharset = QString::fromUtf8( buffer).trimmed().toLower(); - setMetaData("charset", m_request.strCharset); if (!m_request.lastModified.isEmpty()) setMetaData("modified", m_request.lastModified); QString tmp; @@ -2650,8 +2673,6 @@ QByteArray locationStr; // In case we get a redirect. QByteArray cookieStr; // In case we get a cookie. - QString dispositionType; // In case we get a Content-Disposition type - QString dispositionFilename; // In case we get a Content-Disposition filename QString mediaValue; QString mediaAttribute; @@ -3182,7 +3203,7 @@ dispositionBuf--; if ( dispositionBuf > bufStart ) - dispositionFilename = QString::fromLatin1( bufStart, dispositionBuf-bufStart ); + m_request.strFilename = QString::fromLatin1( bufStart, dispositionBuf-bufStart ); break; } @@ -3195,7 +3216,7 @@ dispositionBuf++; if ( dispositionBuf > bufStart ) - dispositionType = QString::fromLatin1( bufStart, dispositionBuf-bufStart ).trimmed(); + m_request.strDisposition = QString::fromLatin1( bufStart, dispositionBuf-bufStart ).trimmed(); while ( *dispositionBuf == ';' || *dispositionBuf == ' ' ) dispositionBuf++; @@ -3204,21 +3225,23 @@ // Content-Dispostion is not allowed to dictate directory // path, thus we extract the filename only. - if ( !dispositionFilename.isEmpty() ) + if ( !m_request.strFilename.isEmpty() ) { - int pos = dispositionFilename.lastIndexOf( '/' ); + int pos = m_request.strFilename.lastIndexOf( '/' ); if( pos > -1 ) - dispositionFilename = dispositionFilename.mid(pos+1); + m_request.strFilename = m_request.strFilename.mid(pos+1); kDebug(7113) << "(" << m_pid << ") Content-Disposition: filename=" - << dispositionFilename << endl; + << m_request.strFilename << endl; } } else if(strncasecmp(buf, "Content-Language:", 17) == 0) { QString language = QString::fromLatin1(trimLead(buf+17)).trimmed(); - if (!language.isEmpty()) + if (!language.isEmpty()) { + m_request.strLanguage = language; setMetaData("content-language", language); + } } else if (strncasecmp(buf, "Proxy-Connection:", 17) == 0) { @@ -3675,17 +3698,17 @@ m_strMimeType = QString::fromLatin1("video/x-ms-wmv"); } - if( !dispositionType.isEmpty() ) + if( !m_request.strDisposition.isEmpty() ) { kDebug(7113) << "(" << m_pid << ") Setting Content-Disposition type to: " - << dispositionType << endl; - setMetaData("content-disposition-type", dispositionType); + << m_request.strDisposition << endl; + setMetaData("content-disposition-type", m_request.strDisposition); } - if( !dispositionFilename.isEmpty() ) + if( !m_request.strFilename.isEmpty() ) { kDebug(7113) << "(" << m_pid << ") Setting Content-Disposition filename to: " - << dispositionFilename << endl; - setMetaData("content-disposition-filename", dispositionFilename); + << m_request.strFilename << endl; + setMetaData("content-disposition-filename", m_request.strFilename); } if (!m_request.lastModified.isEmpty()) @@ -3789,22 +3812,18 @@ kDebug(7113) << "(" << m_pid << ") POST'ing live data..."; QByteArray buffer; - int old_size; - m_bufPOST.resize(0); - do - { + m_bufPOST.clear(); + while(true) { dataReq(); // Request for data result = readData( buffer ); - if ( result > 0 ) - { + if ( result > 0 ) { length += result; - old_size = m_bufPOST.size(); - m_bufPOST.resize( old_size+result ); - memcpy( m_bufPOST.data()+ old_size, buffer.data(), buffer.size() ); - buffer.resize(0); - } - } while ( result > 0 ); + m_bufPOST.append(buffer); + buffer.clear(); + } else + break; + } } if ( result < 0 ) @@ -4785,8 +4804,26 @@ gzputs(m_request.fcache, mimetype.toLatin1()); // Mimetype gzputc(m_request.fcache, '\n'); - if (!m_request.strCharset.isEmpty()) - gzputs(m_request.fcache, m_request.strCharset.toLatin1()); // Charset + if (!m_request.strCharset.isEmpty()) { + gzputs(m_request.fcache, "content-type-charset: "); + gzputs(m_request.fcache, m_request.strCharset.toLatin1()); // Charset + gzputc(m_request.fcache, '\n'); + } + if (!m_request.strLanguage.isEmpty()) { + gzputs(m_request.fcache, "content-language: "); + gzputs(m_request.fcache, m_request.strLanguage.toLatin1()); // Content-language + gzputc(m_request.fcache, '\n'); + } + if (!m_request.strDisposition.isEmpty()) { + gzputs(m_request.fcache, "content-disposition-type: "); + gzputs(m_request.fcache, m_request.strDisposition.toLatin1()); // Content-Disposition + gzputc(m_request.fcache, '\n'); + } + if (!m_request.strFilename.isEmpty()) { + gzputs(m_request.fcache, "content-disposition-filename: "); + gzputs(m_request.fcache, m_request.strFilename.toLatin1()); // Content-Disposition: filename + gzputc(m_request.fcache, '\n'); + } gzputc(m_request.fcache, '\n'); return; --- trunk/KDE/kdelibs/kioslave/http/http.h #709861:709862 @@ -165,6 +165,9 @@ time_t expireDate; // Date when the cache entry will expire time_t creationDate; // Date when the cache entry was created QString strCharset; // Charset + QString strLanguage; // Language + QString strDisposition; + QString strFilename; // Cookie flags enum { CookiesAuto, CookiesManual, CookiesNone } cookieMode;