Version: (using KDE KDE 3.1) Installed from: FreeBSD Ports OS: FreeBSD Hi, I cannot open some URLs with Konqueror (such as http://www.itsyourturn.com/iyt.dll?choose_newgame_type?p=1). Konqueror thinks that it is a file, and asks me if I want to save or open (with that archive tool) this URL.
I cannot reproduce this with the latest Konqueror from the development KDE packages (HEAD 20030405). This probably means the bug is caused by a bad configuration in your end, which I doubt, or that it has already been fixed. However, it should be noted that the site we're talking about reports a login error and asks for a login. Since I have no password and cannot login, I cannot test against the login case. Are you logging in? If you are or if you have ever logged in, then we need a public URL with which to test that results in the same behaviour. The server response is, as far as I can see, Ok: kio_http: (31413) ============ Received Response: kio_http: (31413) "HTTP/1.1 200 OK" kio_http: (31413) "Server: Microsoft-IIS/5.0" kio_http: (31413) "Date: Sun, 06 Apr 2003 12:37:12 GMT" kio_http: (31413) "Cache-Control: no-cache, no-store, private" kio_http: (31413) "Connection: close" kio_http: (31413) "Content-Type: text/html" kio_http: (31413) "Content-Encoding: gzip" kio_http: (31413) "Transfer-Encoding: chunked" kio_http: (31413) "Expires: Wed, 01 Jan 1997 12:00:00 GMT" kio_http: (31413) "Vary: Accept-Encoding" kio_http: (31413) --empty--
Yes, we need to log in to test this. The registration is free I guess. After that, go to "new game" > "post new game". Konqueror will ask if you want to save or open... I've seen this in other websites, but this is the only one I remember.
Confirm the problem, HEAD 20030405. Here's the reply after a log in: kio_http: (18643) ============ Received Response: kio_http: (18643) "HTTP/1.1 200 OK" kio_http: (18643) "Server: Microsoft-IIS/5.0" kio_http: (18643) "Date: Sun, 06 Apr 2003 14:14:09 GMT" kio_http: (18643) "Cache-Control: no-cache, no-store, private" kio_http: (18643) "Connection: close" kio_http: (18643) "Content-Encoding: gzip" kio_http: (18643) "Transfer-Encoding: chunked" kio_http: (18643) "Expires: Wed, 01 Jan 1997 12:00:00 GMT" kio_http: (18643) "Vary: Accept-Encoding" Note there's no Content-Type header. I know from experience that Content-Encoding: gzip works in Konqueror without problems, so I'm guessing the bug is caused by the lack of the Content-Type header. To developers: Is the MIME type being guessed from contents?
Subject: Re: Cannot open some URLs On Sunday 06 April 2003 10:17, Thiago Macieira wrote: > Here's the reply after a log in: > kio_http: (18643) ============ Received Response: > kio_http: (18643) "HTTP/1.1 200 OK" > kio_http: (18643) "Server: Microsoft-IIS/5.0" > kio_http: (18643) "Date: Sun, 06 Apr 2003 14:14:09 GMT" > kio_http: (18643) "Cache-Control: no-cache, no-store, private" > kio_http: (18643) "Connection: close" > kio_http: (18643) "Content-Encoding: gzip" > kio_http: (18643) "Transfer-Encoding: chunked" > kio_http: (18643) "Expires: Wed, 01 Jan 1997 12:00:00 GMT" > kio_http: (18643) "Vary: Accept-Encoding" > > Note there's no Content-Type header. I know from experience that > Content-Encoding: gzip works in Konqueror without problems, so I'm guessing > the bug is caused by the lack of the Content-Type header. > > To developers: Is the MIME type being guessed from contents? Yes, it should. There should be output indicating that the mime type was being derived from the content. Can you check if this is the case ? Regards, Dawit A.
Yes, it's right below it. Sorry for not seeing it before: kparts: slotBrowserMimetype: found application/x-gzip for http://www.itsyourturn.com/iyt.dll?choose_newgame_type?p=1 kio (KIOJob): Job::kill this=0x84672b0 m_progressId=0 quietly=true konqueror: KonqRun::foundMimeType application/x-gzip konqueror: [void KonqView::setLoading(bool, bool)] loading=false hasPending=false konqueror: KonqMainWindow::openView application/x-gzip http://www.itsyourturn.com/iyt.dll?choose_newgame_type?p=1 0x81d6848 konqueror: req.args.frameName= konqueror: req.followMode=false konqueror: req.nameFilter= konqueror: req.typedURL= konqueror: req.newTab= false konqueror: req.newTabInFront= false konqueror: req.openAfterCurrentPage= false konqueror: makeViewsFollow KonqView url=http://www.itsyourturn.com/iyt.dll?choose_newgame_type?p=1 serviceType=application/x-gzip konqueror: changeViewMode: serviceType is application/x-gzip serviceName is current service name is khtml konqueror: Switching view modes... konqueror: Trying to create view for "application/x-gzip" kio (KTrader): KServiceTypeProfile::offers( application/x-gzip,Application ) kio (KTrader): Returning 1 offers kio (KTrader): KServiceTypeProfile::offers( application/x-gzip,KParts/ReadOnlyPart ) kio (KTrader): Returning 1 offers libkonq: application/x-gzip.desktop libkonq: No X-KDE-AutoEmbed, looking for group libkonq: KonqFMSettings::shouldEmbed : serviceTypeGroup=application konqueror: KonqFMSettings says: don't embed this servicetype
While a nice feature to detect the MIME type from contents, isn't there an RFC saying that we should interpret as text/html when no MIME type is given?
Subject: Re: Cannot open some URLs On Tuesday 08 April 2003 10:40, Thiago Macieira 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=56909 > > > > > ------- Additional Comments From thiagom@mail.com 2003-04-08 16:40 ------- > While a nice feature to detect the MIME type from contents, isn't there an > RFC saying that we should interpret as text/html when no MIME type is > given? Nope. See RFC 2616 section 7.2.1.
I see a similar behaviour on http://www.kde-forum.org/ There the Content-Type is set to text/html; charset=ISO-8859-1 and the Content-Encoding is gzip In Gentoo's KDE 3.1.2 everything displays alright, but in CVS HEAD from today I get a listing of binary garbage. Maybe the transparent gzip decompression doesn't work?
kde-forum.org problem is fixed on cvs head.
ismail ( cartman ) donmez wrote: > kde-forum.org problem is fixed on cvs head. Yes, it works now.
Regarding comment 8-10: That's because something on the kde-forum.org server changed. I still experience it with http://golem.de. It has something to do with qt-copy/Qt 3.2beta1 because HEAD compiled against Qt 3.1 works fine.
*** Bug 61899 has been marked as a duplicate of this bug. ***
To the reporters:if you're using one of the Qt3.2 betas, can you please try the final?
I've just recompiled qt-copy from CVS about an hour ago and the bug is still there. I assume qt- copy currently is QT 3.2 Final.
Subject: KDE_3_1_BRANCH: kdelibs/kioslave/http CVS commit by waba: Fix QByteArray handling bug that causes gzip-encoded web-pages to fail with Qt 3.2. (BR56909) CCMAIL: 56909-done@bugs.kde.org M +5 -11 httpfilter.cc 1.6.2.1 --- kdelibs/kioslave/http/httpfilter.cc #1.6:1.6.2.1 @@ -278,15 +278,9 @@ HTTPFilterGZip::slotInput(const QByteArr { bEof = false; - if (headerData.isEmpty()) - { - headerData = d; - } - else - { + // Add data to header. int orig_size = headerData.size(); headerData.resize(orig_size+d.size()); memcpy(headerData.data()+orig_size, d.data(), d.size()); - } zstr.avail_in = headerData.size();