Version: 3.5.7 - 90.2 x86_64 (Opensuse 10.2 rpm) (using KDE KDE 3.5.7) Installed from: SuSE RPMs OS: Linux I use Konqueror frequently to connect to an Openexchange server. I run Konqueror on Opensuse 10.2. I have installed the latest KDE-packages from the Opensuse KDE3 repositories (version 3.5.7-90.2 x86_64). The Login and authentication procedure for the OX5 sever were handled correctly until version 3.5.7-64.1). The Login is not handled correctly anymore. After sending the userid and the password a redirection to a server servlet with a session id is initiated by the server. The page that announces the redirection is shown by Konqueror but afterwards nothing happens and the standard portal page of OX is not displayed. However, as soon as I reload the page (displaying the message for the redirect) a new session id is displayed and then the standard portal page is loaded and displayed. I see this behaviour only on the latest Konqueror versions. Firefox, Opera and IE6 (under Crossover Office) handle the Login procedure perfectly (no reload required, no change of session id, correct and immediate display of the OX portal page as expected). So I suspect that something was changed in a harmful way regarding the handling of auth redirects to servlets during the last versions of Konqueror 3.5. 7. Any ideas? What could I do to test and debug in more detail?
Maybe dupe of this one? http://bugs.kde.org/show_bug.cgi?id=149957
As far as I understood bug http://bugs.kde.org/show_bug.cgi?id=149957 some recent changes of Konqueror affect the http header analysis. See the comment of Maxim who states that " http://lists.kde.org/?l=kde-commits&m=118866783529054&w=2 is likely the culprit, it breaks headers completely". In my opinion it is very likely that a disruption and misinterpretation of header information may also cause the error I see. I had a look at the communication between the server and the browser with wireshark. Interestingly, the server sends a "Refresh" instruction to the browser instead of a "Location" instruction (see excerpt from wireshark output below) . Konqueror does not react to this request (from the server) after having received it. No page request (with GET or POST parameter delivery) to the server appears. As far as I know "Refresh" is not an official part of HTTP 1.1. However, Firefox, Opera and IE support it obviously - and also Konqueror did so in the past. So when analyzing what happened after version 3.5.7-64.1 the developers should have a look at the handling of "Refresh" instructions. ------ Wireshark excerpt : Refresh request from OX server to browser ------------ HTTP/1.1 200 OK Date: Sun, 23 Sep 2007 10:24:11 GMT Server: Apache/2.0.59 (Linux/SuSE) Refresh: 0; URL=/servlet/intranet?SITE=beforeAuth&sessionID=44592467244c15ae0a57100901bf6307 Set-Cookie: open-xchange-session-44592467244c15ae0a57100901bf6307=4d77a7035cfc3168d6354dab76e79ef9; path=/ Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 149 <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US"><head><title>OPEN-XCHANGE SERVER</title> </head><body align="center" bgcolor="#ffffff"> 43 Redirecting to /servlet/intranet?SITE=beforeAuth&sessionID= ...<br> 2f SessionID: 44592467244c15ae0a57100901bf6307<br> e </body></html>
*** This bug has been marked as a duplicate of 149957 ***
I reopened the bug after some discussion with Maksim Orlovich (see the comments for bug 149957). The present impression is that bug 150070 is not a duplicate of bug 149957. The recent corrections to solve bug 149957 did not help for bug 150070. As a next step I shall try to find a way to reproduce the error described above - without using Open-Xchange. Just to make the analysis a little bit easier ...... I think the bug has something to do with the handling of the REFRESH request on the http communication layer (see comment 2 above). If this is true it should be possible to reproduce and provoke the strange behaviour of Konqueror by some simple PHP-programs which generate http redirection headers similar to that of the OX5 server.
Well, I tried to reproduce it by playing back your log with netcat -l (it makes a passable web server for playing back something w/headers intact), and things seem to work right, as long as the connection is closed, anyway. (Any chance things are hanging around doing nothing with the stop button lit up?) My original analysis was wrong, though -- the change I was referring to had to do with passing of unparsed headers to applications. Things like refresh: are parsed by kio-http and passed in separately as well.
I agree meanwhile that the HTTP REFRESH is not the problem. Everything I have tested today in that direction ended with positive results. After my tests I think that Konqueror handles redirects based on Location and Refresh directives correctly. Therefore I had again a look at the IP packages transferred from the OX server with wireshark. I noticed now that the content is transferred in a "chunked" mode (see the HTTP Header Line "Transfer-Encoding: chunked" in my previous example). Could it be that Konqueror in its latest versions has problems with identifying the closure of the chunk package transmissions, i.e. might it be waiting for the final chunk trailer or something like that? Or doesn't it recognize the final "0" ? I shall create an attachment with the relevant output from wireshark for a further inspection. In my opinion everything seems to be OK with the transmission from the OX server -and both Opera and Firefox can handle it. So what about Konqueror and chunked http transmission ?
Created attachment 21757 [details] wireshark output for the "chunked" HTTP transmission of OX5 The attachment shows that the OX5 server sends the xhtml contents of the refresh request in a chunked mode.
The support is there, and it doesn't look changed at all since between 3.5.7 and trunk, I think, though kio-http code is hard to follow, partly due to workarounds for all sorts of buggy servers. (Some servers consider sending content-type too much of a hassle; some even don't bother with the headers and just spit out the data, etc.) Actually, let me ask you a few things: 1) Does the stop button get disabled or not? Does the progress gear icon keep turning or stop? 2) Do we try to load anything else after the redirect page shows up? 3) Other idea: cookies?
Maxim, thank you for you r comments. Here are the answers to your questions: 1) The stop button gets disabled. The xhtml-contents ("Redirecting to /servlet/intranetßsITE=beforeAuth&sessionID=........"; see the attachment) is displayed in the browser window. The progress gear icon stops. 2) The refresh, however, does not take place. I do not see any new page request sent from the browser to the server after the redirect page shows up. For Firefox and Opera instead a GET request is directed to the OX server. Example: GET /servlet/intranet?NAS_ID=56d683067d167bbde405913a056c0163&SITE=top&sessionID =56d683067d167bbde405913a056c0163 HTTP/1.1\r\n 3) I have verified that the requested cookie has been set. It gets displayed when you search for it in Konquerors own management tool for cookies. I have double checked that by deleting all older cookies before performing a new login attempt to the OX server and by comparing the name and value with the wireshark output. So the redirect page is displayed, the cookie is set, the stop button and the gear icon are inactive - Konqueror nevertheless does not react to the Refresh request. Strange , isn't it? Any other points or Konquerero settings I should check?
Maksim (I am sorry that I wrote your name wrongly last time), I verified again that the problem came with one of the newer versions of Konqueror. Furthermore I wanted to exclude that there is another bug somewhere in my system. So I did the following: I installed Opensuse 10.2 in a VMware environment on a completely different system with a different processor (Intel 32bit instead of AMD, 64bit dual core). I installed the following versions of kdebase3 and kdelibs3 - this time of course the 586 packages and not the x86_64 packages kdebase3 vers. 3.5.7-23.1 kdelibs3 vers. 3.5.7-31.1 Everything OK ! kdebase3 vers. 3.5.7-64.1 kdelibs3 vers. 3.5.7-64.1 Everything OK ! kdebase3 vers. 3.5.7-91.2 kdelibs3 vers. 3.5.7-80.1 Not OK! Login stops as described after the redirect page is shown. So at some point after sub-version 64.1 something was definitely changed that lead to this bug. And as I installed newer versions of only kdebase3 and kdelibs3 and left any other KDE package untouched, it has to do with changes of these 2 specific packages.
Thank you for all your legwork. One more thing that may be useful: could you perhaps get the RPM changelogs for kdebase and kdelibs in the range? See, I basically have no idea of what exactly is in the version you're using. SUSE applies a lot of patches, most of which are from our stable branch, and so the version you're using is some unknown mix of 3.5.7 and soon-to-be 3.5.8. If we can figure out what exactly got changed, it would make things so much easier. (Of course, if you can tell me where to grab that SRPMs for these package revisions, that will make things even easier)
I get my rpm-packages from the following address: http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_10.2/x86_64/ I downloaded the 64.1 versions on Aug, 12th. So any entries in the changelogs since this date should be interesting. I'll create 2 attachements containing the changelogs for kdebase3 and kdelibs3. I hope that helps. There is one entry for kdelibs3 that sounds interesting with respect to "chunked" contents: * Fr Sep 14 2007 dmueller@suse.de ......- fix cross domain cookie injection (kde bug #134421) - http kioslave fixes to make it work with big and chunked http response headers ....... Maybe it makes sense to have a look at the corresponding modifications? Some speculation: In my opinion you use chunked transfer when you have large contents and you want to ensure that the whole body of a http (extending over several TCP/IP packets) message is received completely by the receiving application. Interestingly, in our case the whole body fits into one TCP IP packet, only. This should, of course, not have any influence on the application level. But who knows? Maybe this case is nevertheless not treated correctly anymore? I want to stress another point: When I manually (!) refresh the page after the display of the (standing) redirection page in the browser by pressing the browsers reload button I first get a warning the the contents of the last page depends on parameters which will be transferred again. As soon as I agree I do get the expected portal page of the server - it seems that then (due to some strange effects) the login and redirection are handled correctly. The sessionId, however, changes in comparison to what was transferred from the server during the first attempt.
Created attachment 21766 [details] changelog kdebase3
Created attachment 21767 [details] changelog kdelibs3
The source rpms from Suse can be found at http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_10.2/src/
Thanks, doesn't enlighten me in any way :(, but an another devel might have found an another instance of the same bug: Bug #150904
SVN commit 726539 by adawit: - Forward port the fix for BR 150904 and 150070 from KDE 3.5 branch. BUG:150904 BUG:150070 M +4 -6 http.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=726539