| Summary: | Confusing reaction on status code 204 (No Content) | ||
|---|---|---|---|
| Product: | [Unmaintained] kio | Reporter: | Per Ångström <per.angstrom> |
| Component: | http | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | adawit, germain, per.angstrom |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.6.4 | |
| Sentry Crash Report: | |||
|
Description
Per Ångström
2001-08-15 21:35:22 UTC
On Wednesday 15 August 2001 02:35 pm per.angstrom@autark.se wrote: > Package: konqueror > Version: KDE 2.2.0 > Severity: normal > Installed from: SuSE RPMs > Compiler: Not Specified > OS: Linux > OS/Compiler notes: Not Specified > > When Konqueror receives a status code of 204 (No Content) it will show an > error dialog saying "Data have been successfully sent". I find this both > confusing and annoying. Huh wasn't this changed recently? Cheers Waldo -- KDE 2.2: We deliver. On Wednesday 15 August 2001 18:02 Waldo Bastian wrote: > On Wednesday 15 August 2001 02:35 pm per.angstrom@autark.se wrote: > > Package: konqueror > > Version: KDE 2.2.0 > > Severity: normal > > Installed from: SuSE RPMs > > Compiler: Not Specified > > OS: Linux > > OS/Compiler notes: Not Specified > > > > When Konqueror receives a status code of 204 (No Content) it will show > > an error dialog saying "Data have been successfully sent". I find this > > both confusing and annoying. > > Huh wasn't this changed recently? Yes it was. In fact I just checked and and we no longer send any error message back to the client under such conditions. We simply set the error flag to true to stop any further processing and return. Here is the applicable code snippet: else if ( m_responseCode == 204 ) // No content { // error(ERR_NO_CONTENT i18n("Data have been successfully sent.")); // Short circuit and do nothing! m_bError = true; return false; } IMHO there is no way this is kio_http from KDE 2.2! Probably from one of the early beta's or 2.1.2... Regards Dawit A. >IMHO there is no way this is kio_http from KDE 2.2! Probably from one of the early beta's >or 2.1.2... Well for all I know I'm running version 2.2beta1 (SuSE RPMs). Anyway I'm glad that the error dialog will soon be gone. On Wednesday 15 August 2001 11:23 pm Per Angstrom wrote: > >IMHO there is no way this is kio_http from KDE 2.2! Probably from one of > > the early beta's > > >or 2.1.2... > > Well for all I know I'm running version 2.2beta1 (SuSE RPMs). Anyway I'm > glad that the error dialog will soon be gone. On Thursday 16 August 2001 02:23 Per Angstrom wrote: > >IMHO there is no way this is kio_http from KDE 2.2! Probably from one of > > the early beta's > > >or 2.1.2... > > Well for all I know I'm running version 2.2beta1 (SuSE RPMs). Anyway I'm > glad that the error dialog will soon be gone. But in the bug report you said 2.2 which can easily be interpreted as 2.2 final and confuse people. Next time please try to use the exact version number if possible or atleast a better description like 2.2 beta (don't remember which one) so we can easily tell if what your have reported has already been fixed and get you an answer much quicker :) Thanks for your report just the same... Regards Dawit A. Sorry I confused everyone by saying '2.2' in the original report when in fact I was referring to '2.2beta1'. The thing is '2.2' was the most applicable option available in the Bug Report Wizard so I picked that one not knowing that '2.2 final' was being released the same day. Anyway now I'm definitely running '2.2' and I can see that the error dialog is gone. And that is very good. But there is still a problem: The "busy" icon doesn't stop pulsating so I have to press cancel to make it stop. Users will surely think there is a problem when in fact there is not. I'm sure this cannot be the intended behaviour. Best regards /Per Ã. In Konqueror 2.92 the behavior has changed from annoying to=20 unacceptable. Konqueror will now try to open the output instead of=20 treating the transaction as a no-op. You can try this URL for a demo: <http://www.autark.se/204.pl> and=20 compare with how Mozilla handles it. To see the problem in a more=20 realistic context try=20 <http://www.autark.se/large_textarea_field_test_page.html>. In Konqueror 3.0.3 I can see that my comment #7 is still valid, so I'm reopening the bug. This works exactly like Mozilla in the current development version. It should also work properly in 3.1 release as well as the code that deals with handling 204 has not changed. Please feel free to re-open if that is not the case for you. Regards, Dawit A. In Konqueror version 4.1.3 (KDE 4.1.3) "release 52.2", I get an error dialog with no text when I click on http://www.autark.se/jump.pl . This must be a regression. I find I cannot reopen bugs, so I'm setting this to UNCONFIRMED. in trunk of a week ago, here is what I see: http://www.autark.se/jump.pl : the 204 triggers a kate part that contains an empty text. No error message. http://www.autark.se/large_textarea_field_test_page.html : a dialog request to open a text/plain document in kate is displayed. Accepting the request leads to the popping up of an oter dialog displaying an empty error message. So I think it's gotten a bit worse ;( Setting status to NEW. I'm seeing similarly wrong behavior in rekonq, version 0.6.0, using KDE Development Platform 4.5.1 (KDE 4.5.1). Wow. An 11 year old bug report and one I commented on 8 years ago. Oh well this was easy enough to resolve if only I had the same knowledge then :) First this is not really a konqueror bug and hence why it was not fixed for this long. Second the problem is actually caused by the server itself for which we do not yet have a workaround unlike the other browsers. Why is this a server problem ? Because it sends a "Content-Type" header with a 204 No Content response, which it should not be doing. For example, here is the result from trying the second (POST related) link in comment #7: HTTP/1.1 204 No response Date: Wed, 04 May 2011 13:34:00 GMT Server: Apache Content-Length: 0 Connection: close Content-Type: text/plain; charset=iso-8859-1 Anyhow, the fix is trivial and would probably have been resolved sooner if it was reported against the correct product/component, kio/http. Git commit 3d2d3998c493a72b052eeec70d07285f27982b86 by Dawit Alemayehu. Committed on 05/05/2011 at 02:58. Pushed by adawit into branch 'KDE/4.6'. When the server responds with a '204 No Content' status, disregard any content-type header it may have included in the response header. Make KRun treat a KIO::ERR_NO_CONTENT error message as an indicator that no further action needs to be taken instead of an actual error. BUG: 30667 FIXED-IN: 4.6.4 M +2 -2 kio/kio/accessmanagerreply_p.cpp M +25 -16 kio/kio/krun.cpp M +12 -8 kioslave/http/http.cpp http://commits.kde.org/kdelibs/3d2d3998c493a72b052eeec70d07285f27982b86 Git commit 24d2ba92149888b0a9386d9d42bb72a1592e16f8 by Dawit Alemayehu. Committed on 05/05/2011 at 02:58. Pushed by adawit into branch 'master'. When the server responds with a '204 No Content' status, disregard any content-type header it may have included in the response header. Make KRun treat a KIO::ERR_NO_CONTENT error message as an indicator that no further action needs to be taken instead of an actual error. CCBUG: 30667 (cherry picked from commit 3d2d3998c493a72b052eeec70d07285f27982b86) M +2 -2 kio/kio/accessmanagerreply_p.cpp M +25 -16 kio/kio/krun.cpp M +12 -8 kioslave/http/http.cpp http://commits.kde.org/kdelibs/24d2ba92149888b0a9386d9d42bb72a1592e16f8 |