Closed Bug 114839 Opened 24 years ago Closed 24 years ago

Multipart/x-mixed-replace seems broken since 0.9.5

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: roberto, Assigned: darin.moz)

References

(
URL
)

Details

See url, which sends a multipart message in 6 parts, 1 second interval. Worked in Mozilla 0.9.4, broken in 0.9.5.
nc4 asks me to download multipart/x-mixed-replace
Assignee: asa → darin
Component: Browser-General → Networking: HTTP
QA Contact: doronr → tever
> nc4 asks me to download multipart/x-mixed-replace Last part had wrong mimetype. Fixed that. Unfortunately (for debugging purposes, that is), this script customizes the multipart to what the agent can handle: Gecko gets true multipart in html + CSS other Netscape's get true multipart in text/plain MSIE 5+ gets fake multipart (with CSS) All based on the user agent string. To see the exact output for mozilla, do a telnet to port 80, with the following input: GET /test_multipart.en.pl HTTP/1.0 User-Agent: Mozilla (Gecko) Host: hoppa.com
what happens if you don't change location via script in the parts?
> what happens if you don't change location via script in the parts? I've changed the script, and removed the javascript which changed the location.hash. Now the multipart works. However there is still a problem: when the content of the multipart only contains a single line of text, the body is not shown. Compare these pages: http://hoppa.com/test_multipart.pl showing a sequence of 5 pages each with one line of text, title changes, body is not chown with: http://hoppa.com/test_multipart.pl?lines=8 same as the first but 8 lines are shown (printed with 1 second intervals) You now see display only occurs after the second line. Note that at each line the buffer to the client is flushed (using apache's rflush)
I see all 5 parts in the first testcase on linux build 2001-12-10-08. Chances are, you're running into paint-suppression. We don't paint a new page for 1.2 seconds or as long as it takes to lay out, whichever is shorter. So in your case, if the paint-suppression takes longer than 1sec you will not see the intermediate pages.
exactly! the display seems to depend on network latency, etc. marking INVALID. cc'ing hyatt so he can be aware of the unfortunate side effects of paint suppression and multipart/x-mixed-replace content.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
The issue of the location.hash causing trouble within multipart message still remains. Should I issue separate bug report for this?
yeah, that sounds like it should be filed under a separate bug report. thx!
verified INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.