The bug is still there with kde 3.2.1. It is sometimes occuring with http://groups.yahoo.com/group/groupname/message/number, where groupname is a yahoo group and number a message number.

you don't happen to have a working URL?

Created attachment 8795 [details]
php file to test this bug

No, I have no working URL. Yahoo rearranged their URLs, and we created a
workaround on our internal site.
But you can test this bug with the attached php file. Put it on a web server,
and load it. Don't allow the cookie to be set, and you'll get the described
behavior. I tested it with konqueror 3.3.1, and the error message came after
several reloads and not on the first time, so this problem is fixed and the
behavior fine now.
However, if you comment the header() line and uncomment the three echo lines,
the reloading check is not performed at all. IMHO the behavior should be the
same wether the redirect works via http headers or html meta tags.

a test case where this bug happens is http://www.megatokyo.de/?id=106
but strange enough it happens only when the redirect target contains german umlauts.

here's the curl -I output for that url:
HTTP/1.1 302 Found
X-Powered-By: PHP/5.1.4
Set-Cookie: MegaTokyoID=AURpLCwiAfE=; expires=Tue, 10 Jul 2007 19:36:38 GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html;charset=UTF-8
Content-Language: de
Location: http://www.megatokyo.de/comic/de0106/ping-das-ps2-zubehör
Content-Length: 0
Date: Mon, 10 Jul 2006 19:36:38 GMT
Server: lighttpd/1.4.11
Connection: close

I cannot reproduce effects mentioned in comment #3 with konq 3.5.4.
So probably all fixed now?

The redirect error on url mentioned above in comment #4 is a real redirect loop (verified with ethereal trace). Konqueror does not seem to notice the Location: header is already UTF8 encoded and tries to UTF8 encode the url in the header again and thus corrupting it. This combined with some server smarts trying to redirect konqueror back to the correct page leads to a loop.
But that should maybe be a seperate bug from this one.

so, should i open a separate one for megatokyo?

Can reproduce none of the issues above, everything seems to work fine. KDE 3.5.4, Kubuntu Dapper.

closing worksforme

of course http://www.megatokyo.de/comic/de0106/ping-das-ps2-zubehör works now, since lapo (the webmaster) made a workaround especially for konqueror...

still broken: http://www.megatokyo.it/k-bug.php is a testcase.

I'm having a similar problem in KDE 4.1.1, though I don't know if it's of the same origin.

On my private web server I have a small,simple php gallery script which generates thumbnails (and caches them later) on the fly. Thus, handling a large number of thumbnail generation requests (ie. first time views) at the same time is not possible. This results in missing images in the picture listing in konqueror, though firefox and IE work well.

I've established that the apache2 server, when it can't handle the request right now, sends 302 Found message and expects the browser to request the image later. Konqueror doesn't do this and simply draws the 'missing image' thing. As I said, firefox has no problems.

My web server says something like:
62.xx.xx.xx - user [29/Sep/2008:01:04:57 +0200] "GET /~user/photo/.scry/cache/Ustronie!IMG_0190_56x75.JPG HTTP/1.0" 200 1753 "http://xxx/~user/photo/index.php?v=list&i=0&p=Ustronie" "Mozilla/5.0 (compatible; Konqueror/4.1; Linux) KHTML/4.1.1 (like Gecko)"
62.xx.xx.xx - user [29/Sep/2008:01:04:58 +0200] "GET /~user/photo/index.php?v=image&i=100x75&p=Ustronie/IMG_0101.JPG HTTP/1.0" 302 - "http://xxx/~user/photo/index.php?v=list&i=0&p=Ustronie" "Mozilla/5.0 (compatible; Konqueror/4.1; Linux) KHTML/4.1.1 (like Gecko)"
62.xx.xx.xx - user [29/Sep/2008:01:04:58 +0200] "GET /~user/photo/.scry/cache/Ustronie!IMG_0102_100x75.JPG HTTP/1.0" 200 2120 "http://xxx/~user/photo/index.php?v=list&i=0&p=Ustronie" "Mozilla/5.0 (compatible; Konqueror/4.1; Linux) KHTML/4.1.1 (like Gecko)"
62.xx.xx.xx - user [29/Sep/2008:01:04:58 +0200] "GET /~user/photo/index.php?v=image&i=100x75&p=Ustronie/IMG_0104.JPG HTTP/1.0" 302 - "http://xxx/~user/photo/index.php?v=list&i=0&p=Ustronie" "Mozilla/5.0 (compatible; Konqueror/4.1; Linux) KHTML/4.1.1 (like Gecko)"
62.xx.xx.xx - user [29/Sep/2008:01:04:58 +0200] "GET /~user/photo/index.php?v=image&i=100x75&p=Ustronie/IMG_0103.JPG HTTP/1.0" 302 - "http://xxx/~user/photo/index.php?v=list&i=0&p=Ustronie" "Mozilla/5.0 (compatible; Konqueror/4.1; Linux) KHTML/4.1.1 (like Gecko)"
62.xx.xx.xx - user [29/Sep/2008:01:04:58 +0200] "GET /~user/photo/.scry/cache/Ustronie!IMG_0101_56x75.JPG HTTP/1.0" 200 1704 "http://xxx/~user/photo/index.php?v=list&i=0&p=Ustronie" "Mozilla/5.0 (compatible; Konqueror/4.1; Linux) KHTML/4.1.1 (like Gecko)"

re: comment #11: please also see bug #171368.
Any chance you could get a wireshark log of the loop you're seeing (properly redacted, of course) --- it'd be interesting to see what the server sends a Location: for the 302.

Well it seems that it's not a bug related to http 302 after all. The script works a tid-bit differently from what I thought (php posts 302 Temporarily Moved with the Location of the cached image, thus forcing the browser to make 2 requests).

However, the problem now seems a bit different: konqueror sometimes does the full 2 requests, sometimes it only does the first one (getting the 302 but not the image) and sometimes fails to create a HTTP request for some images at all! The page is 1/3 populated with images and after that there are only images here and there. It seems as if konqueror runs out of kio_http processes to post the requests and after that fails without retrying. Anyone heard of a similar bug or shall I open a new one?

Please do a separate report. I might have a guess as to what it is, but seems off-topic for this report now.

I've created a new bug report here: http://bugs.kde.org/show_bug.cgi?id=171878 I hope this gets fixed :) If there's anything more I can check, feel free to mail me.

SVN commit 1061440 by adawit:

- Workaround brain dead sites that return violate the spec and return 
  a 401 without a WWW-Authenticate header field.
- Correctly escape redirection urls that contain non-ascii/non-latin1
  characters.

BUG:61235
BUG:215736


 M  +96 -85    http.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1061440

*** Bug 130573 has been marked as a duplicate of this bug. ***