| Summary: | [testcase] Konqueror hangs loading a "server push" image stream (Content-Type: multipart/x-mixed-replace) | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Daniel Kabs <daniel.kabs> |
| Component: | khtml part | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | arvidjaar, jtamate, marcus |
| Priority: | NOR | ||
| Version: | 4.7.2 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Daniel Kabs
2004-06-24 12:41:47 UTC
This is a testcase that exposes Konqueror's inability to display a jpeg server push correctly. Have a look at http://bugzilla.mozilla.org/attachment.cgi?id=118643&action=view This is a webpage containing an image. The image SRC attribute points to a CGI script that creates an image stream (aka "server push"). As you can see, you see nothing :-) I checked this with Konqueror 3.3 on KDE 3.3.0 and Server Push did not work. Update: I had a look at the RFC :-) RFC 2046 is quite clear about the syntax of the "Multipart Media Type" which a server push uses (see section 5.1 of that document). Especially about the characters terminating a header line: CRLF. Until I read the RFC I thought that LF was sufficient because Mozilla accepted the stream and displayed it properly. Therefore the stream format has been changed to be RFC compliant by sending CRLF as line terminating characters. I hoped this would resolve this issue with Konqueror, but it didn't :-( Basically, this is unsupported inside <image>. But <object> should work. *** Bug 123614 has been marked as a duplicate of this bug. *** *** Bug 120220 has been marked as a duplicate of this bug. *** <object> doesnt work for me there :/ what should? Maksim, support for server push is a nice thing to have. So you recommend I should propose this as feature request instead? On the other hand, for the time being konqueror munches the stream without digesting it until it explodes which Unix prevents by swapping until the system deadlocks. Not a nice thing. Want to try out :-) Open the testpage referenced above and wait a few hours. See how konqueror starts to eat up your system's memory... Cheers Daniel Just checked with Safari 3.0.4 on Mac OS X "Leopard". It works there! Obviously Apple developers implemented support for "server push" in WebKit. As WebKit is a derivative of KHTML, is it possible to backport this feature to KHTML? Just tried with older Safari 2.0.4 and it works there, too. This browser shows 2005 in the about box. It seems that Apple implemented support for content-type: multipart/x-mixed-replace years ago. Just browsed apple's webkit source code and the change logs using http://trac.webkit.org This is what I found: 2005-02-24 http://trac.webkit.org/projects/webkit/changeset/8685 Apple acknowledged this very bug and worked around it by *not* loading multipart-x-mixed-replace content. 2005-09-08 http://trac.webkit.org/projects/webkit/changeset/10489 http://trac.webkit.org/projects/webkit/changeset/10490 Appled implemented support for multipart/x-mixed-replace content. Confirmed on trunk r794020. In contrast to 3.5.9 the error event is triggered. @David or @Maksim. duplicated bug 123614 is fixed. Is this bug also fixed? I still see this problem using Konkqueror 4.7.2 (Ubuntu 11.10) Open the following testcase in Konqueror http://appcam.mobotixcam.de:2080/control/faststream.jpg?html&stream=full Authorization Credentials (type without the quotes!) user : "user" password: "Firefox" (In reply to comment #12) > Confirmed on trunk r794020. In contrast to 3.5.9 the error event is triggered. Please don't use the testcase in comment #1 any more as it uses a webcam that does not exist any more. Dear user, KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6. Please migrate to use a QWebEngine based HTML component. We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes. For security issues, please see: https://kde.org/info/security/ Sorry that we did not fix this issue during the life-time of KHTML. Greetings Christoph Cullmann |
