I've noticed (and confirmed using whireshark) that when a webserver that I have on localhost replies 303, with a new location to go, rekonq will not issue a new request for that location right away. It will instead pause for a while, then the server will have a timeout and close the connection, and then after about 6-7 seconds rekonq will open a new connection and perform the request. This makes the browser VERY VERY slow even for small simple pages. Reproducible: Always The response is something like this: HTTP/1.1 303 Found Server: weborf/0.14 (GNU/Linux) Location: /index.html
Uhm apparently konqueror has the same issue, so I guess it belongs to some kde library.
Can you please go ahead with your tests and confirm the same with konqueror (another browser using kio for its network layer) and not with opera or qupzilla (2 browser qtwebkit based but using QNAM for network) 2013/5/12 Salvo LtWorf <tiposchi@tiscali.it> > https://bugs.kde.org/show_bug.cgi?id=319717 > > Bug ID: 319717 > Summary: Delayed request in case of redirect > Classification: Unclassified > Product: rekonq > Version: 2.2.1 > Platform: Debian unstable > OS: Linux > Status: UNCONFIRMED > Severity: normal > Priority: NOR > Component: general > Assignee: adjam7@gmail.com > Reporter: tiposchi@tiscali.it > > I've noticed (and confirmed using whireshark) that when a webserver that I > have > on localhost replies 303, with a new location to go, rekonq will not issue > a > new request for that location right away. > > It will instead pause for a while, then the server will have a timeout and > close the connection, and then after about 6-7 seconds rekonq will open a > new > connection and perform the request. > > This makes the browser VERY VERY slow even for small simple pages. > > Reproducible: Always > > > > > The response is something like this: > HTTP/1.1 303 Found > Server: weborf/0.14 (GNU/Linux) > Location: /index.html > > -- > You are receiving this mail because: > You are the assignee for the bug. >
Yes, opera (chromium too) works perfectly fine, doing the 2nd request almost immediately.
(In reply to comment #0) > I've noticed (and confirmed using whireshark) that when a webserver that I > have on localhost replies 303, with a new location to go, rekonq will not > issue a new request for that location right away. > > It will instead pause for a while, then the server will have a timeout and > close the connection, and then after about 6-7 seconds rekonq will open a > new connection and perform the request. > > This makes the browser VERY VERY slow even for small simple pages. > > Reproducible: Always > > > > > The response is something like this: > HTTP/1.1 303 Found > Server: weborf/0.14 (GNU/Linux) > Location: /index.html Can you provide the entire request and response headers? It is hard to know unless we have more detailed information. You could follow the instructions outlined in the url listed below to enable debug areas 7103 and 7113 to get the entire request and response headers: http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves#How_to_get_debug_output
Cannot reproduce. You need to provide the information requested in comment#4 or a URL where we can reproduce the behavior.
GET / HTTP/1.1 Host: localhost:8080 Connection: keep-alive User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) rekonq Safari/534.34 Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8 Accept-Encoding: gzip, deflate, x-gzip, x-deflate Accept-Charset: utf-8,*;q=0.5 Accept-Language: it,en-US;q=0.9,en;q=0.8 DNT: 1 HTTP/1.1 303 Found Server: weborf/0.14 (GNU/Linux) Location: /index.html At this point the connection gets closed, and after a few seconds this happens: GET /index.html HTTP/1.1 Host: localhost:8080 Connection: keep-alive User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) rekonq Safari/534.34 Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8 Accept-Encoding: gzip, deflate, x-gzip, x-deflate Accept-Charset: utf-8,*;q=0.5 Accept-Language: it,en-US;q=0.9,en;q=0.8 DNT: 1 HTTP/1.1 200 OK Server: weborf/0.14 (GNU/Linux) Content-Length: 5 Accept-Ranges: bytes ETag: "1387799091" ciao
Dawit, does comment #6 provide the requested information? Please set the bug status.
No response, changing status.
(In reply to comment #7) > Dawit, does comment #6 provide the requested information? Nope. The information requested was the output from kio_http and not the request/response output obtained by other means. That does not help us debug what the problem with kio_http might be in this particular case. FYI, there is a good redirection test site at http://greenbytes.de/tech/tc/httpredirects/
The request/response is sniffed with wireshark, not generated by other means. You could for example use netcat to emulate the server's response and debug what happens. ``` cat fake_response.txt | nc -l -p8080 ```
Salvo, I am not sure if the information given in comment #10 is sufficient to reproduce. If you can give a step-by-step explanation, it could help developers fix the issue.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
If developers can't reproduce an HTTP issue by looking at the dump of the network requests and responses that occurred, besides fixing it myself, I really don't know what "MOREINFO" could possibly mean.
Is this issue still present with Konqueror 5?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!