Version: (using KDE 4.2.2) Compiler: gcc-4.3.2 OS: Linux Installed from: Fedora RPMs With konqueror from 4.2.1, I am able to browse to this URL and login to the form on the page: https://admin.fedoraproject.org/accounts/login/ With konqueror from 4.2.2 this does not work. konqueror does not succeed in loading that web page. firefox also works with this page. The page is a little tricky as it is returning a response code of 401 Unauthorized and the page that you actually log into is contained in the body of the response. I've tried changing the server in any of the following ways without success: * Have no WWW-Authenticate header. This is how it was working with 4.2.1 and how it is set up right now. * Have a fake WWW-Authenticate header. Same behaviour as with no header. * Use Pubkey or KerberosV4. Same behaviour as no header. * Use response code 403 instead of 401 with each of the variants on the WWW-Authenticate header given above. Yields the same behaviour as above. * Use Basic Auth. this pops up the basic auth dialog box but of course, I can't authenticate to that without hooking up my application to handle that instead of the login form. Unfortunately, our web applications depend on giving a 401 or 403 response code so that scripts that talk to the app work so we can't just return a 200 or a redirect. We can change the WWW-Authenticate header to any necessary value as long as the page continues to show the response body in firefox, and other browsers. However, konqueror-4.2.2 seems to have lost the ability to display the response body.
I did make changes in code related to showing the web server's "error page" vs. just showing just a canned message with the error code. Will investigate...
Another possible complication, is that in fedora, kde-4.2.2 and newer is built against qt-4.5.0, whereas kde-4.2.1 was built against qt-4.4.3
I was wrong about the 403 response code. With the 403 response code the page loads the response body as expected. It's only with the 401 response code that konqueror spins, waiting for something. I'm guessing since 403 is Forbidden with no possibility of recovery that we immediately go to code that displays the response body as the error page. With 401, we must hit some code that tries to negotiate how to authenticate. That code seems to be breaking if there's either no header to tell what methods the server recognizes or the header does not contain any method that the client-side can use.
I just realized one thing about my last message: I upgraded from 4.2.2 to 4.2.3 between my two tests. So it's possible that 4.2.2 was broken for both 403 and 401 response codes but 4.2.3 is only broken for 401 codes.
A bit more poking by various people shows that arora has the same problem but midori (the gtk webkit-based browser) does not. This has lead to speculation that it's a qt-related bug.
Seems this may have gotten fixed somewhere along the line, using qt-4.5.2 + kde-4.2.98, I can no longer reproduce this particular problem. anyone else?
I can but there's been some changes on both the client and server so it needs some explaining: Server side, I've changed our instance to use 403 instead of 401 as that seems to work with konqueror. So https://admin.fedoraproject.org/accounts/login is no longer going to show the issue. I've temporarily set: https://admin.stg.fedoraproject.org/accounts/login to return 401 and the issue still exists there. If a test URL is needed in the future, I can turn this on pretty much anytime (but it will start returning 403 whenever we update the libraries on that machine to test new versions). Client side: * arora now works with a 401 return code. This is arora-0.8.0. * konqueror still fails to load the page. This comes from kdebase-4.2.4 qt-4.5.2 kdelibs-4.2.4
Tried again with: kdelibs-4.2.98-3.fc11.i586 kdebase-4.2.98-1.fc11.i586 qt-4.5.2-1.fc11.i586 arora-0.8.0-1.fc11.i586 arora still works; konqueror still fails on https://admin.stg.fedoraproject.org/login Finding out from rdieter if there's other things I should try updating.
Confirmed with rdieter that the URL doesn't work for him either. Our staging server redirects to the production site when you go to http:// instead of https:// which caused the confusion.
Updated information: Tried the patch in this bug: https://bugs.kde.org/show_bug.cgi?id=186763 no change. Tried with arora-0.9.0, with that I need to have a WWW-Authenticate header to make arora work. 401 response code and the header: "WWW-Authenticate FormAuth" arora works. konqueror still spins. Current versions: kdelibs-4.3.1-4.fc11.i586 kdebase-4.3.1-2.fc11.i586 qt-4.5.2-3.fc11.i586 arora-0.9.0-1.fc11.i586
A small comment from HTTP land workin on HTTP specifications... A 401 without proper WWW-Authenticate headers is an invalid HTTP response and clients are in their full rights to completely reject such messages as malformed. Additionally it's not reasonable to expect browsers to display the body of 401 responses unless the user cancels authentication or if none of the indicated authentication schemes is supported by the browser. And even with a valid WWW-Authenticate header there is no guarantee the body will be displayed. Some browsers thinks that server-generated error messages is better hidden from the user.. But this obviously does not excuse konqueror for getting lost spinning somewhere... no matter how malformed the message is it should take some action.
The header is not malformed, though. The spec requires a WWW-Authenticate header to be sent with 401 which is what is being done here. For arora, all that's changed is that 0.8 didn't require strict compliance to the spec (as seems to be true for other browsers from googling) whereas 0.9 requires the header. konqueror fails even when the header is correct. Since the authentication method is not supported by the client, it SHOULD present the body to the user according to the spec: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2 If the browser ignores the spec and attempts to hide all error messages from the server from the user then we've already lost as the framework depends on returning an error response code. This doesn't appear to be the case with konqueror, though, as it returns the body when a 403 is given. Reading the comments for the patch, http://reviewboard.kde.org/r/1236/diff/ it looks like the problem here is in the code path where an error page is returned with a 401 error code.
I think the issue I'm experiencing might be related. In my case, using KDE 4.3.1 and Qt 4.5.2 I have a standard .htaccess based http basic auth enabled apache. I don't care about the 401 response body, I'm using this in the traditional sense. Konqueror asks me for credentials, and I supply them. After that konqueror pretty much sit and spins indefinitely. Running strace on the related kio_http process shows it sitting in a select call. The select is waiting for read access on a single descriptor which is a unix socket to the klauncher process that started the slave. This may be normal, but I am not sure. A wireshark log shows a connection to the server, the 401 response sent, and the connection is tore down. It appears no attempt to connect with the provided credentials is ever made.
*** Bug 198418 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 205088 ***