Closed Bug 76816 Opened 19 years ago Closed 3 years ago
View Source shows the entire multipart response on a Bugzilla buglist (was: tries to DL Bugzilla buglist as multipart/x-mixed-replace)
17.58 KB, text/plain
43.63 KB, text/plain
2001041908 (and 0417) mac trunk. Goto URL. View Source. Result: A blank window covering a file save dialog, indicating that the file MIME type is multipart/x-mixed-replace. Expected result:The source should be displayed just like other pages. Could be dependent on bug 76657, so I will test again in the next build.
seeing this on linux as well : OS,Platform ->all
OS: Mac System 9.x → All
Hardware: Macintosh → All
Setting to 1.0.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Summary: View Source tries to DL the Today's bug page as multipart/x-mixed-replace → View Source tries to DL Bugzilla buglist as multipart/x-mixed-replace
*** Bug 83859 has been marked as a duplicate of this bug. ***
*** Bug 85153 has been marked as a duplicate of this bug. ***
*** Bug 88812 has been marked as a duplicate of this bug. ***
*** Bug 90203 has been marked as a duplicate of this bug. ***
*** Bug 93151 has been marked as a duplicate of this bug. ***
I see this also when trying to view source on a bugzilla query response
*** Bug 98853 has been marked as a duplicate of this bug. ***
*** Bug 100436 has been marked as a duplicate of this bug. ***
*** Bug 103152 has been marked as a duplicate of this bug. ***
*** Bug 104574 has been marked as a duplicate of this bug. ***
*** Bug 104736 has been marked as a duplicate of this bug. ***
*** Bug 105635 has been marked as a duplicate of this bug. ***
*** Bug 111814 has been marked as a duplicate of this bug. ***
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Another page where a similar thing happens: http://computer.history.museum/bldg/ It claims that this is an unknown MIME type. Mozilla is getting to be a really nice browser now, but one of the handful of really annoying things about it is the extreme flakiness of the "View Source" feature. If you can get this working reliably, Mozilla will be really great!
This seem to have a lot of duplicates. Moving to 0.9.9.
*** Bug 134270 has been marked as a duplicate of this bug. ***
*** Bug 134956 has been marked as a duplicate of this bug. ***
No one seems to have considered a basic question here. "What should view-source show on a multipart page"? All the data as it came from the server raw? (That could run into issues if one of the parts was, say, a gif or worse yet if the multiple parts are all text but in different encodings.) The source of the last part? (This could be quite interesting to do in the current architecture). The source of the first part? The source of the "current part" (what if the user hit 'stop' while the multipart doc was loading?) We should decide this question first and foremost.
#23 How do other browsers handle this? How did earlier Netscape versions?
> How do other browsers handle this? How did earlier Netscape versions? Tested NS 4.76 on Linux and IE 5.0 on Solaris (which is pretty much identical to IE 5.0 on Windows). That's all I have to test: 1) Load a buglist. Wait for it to completely load. Then view source: NS4 -- shows source of last part IE5 -- shows first 1/5 of the source of the last part (and it was a fairly small query -- 20 bugs or so) 2) Load a buglist. Hit stop on the "Please stand by..." screen NS4 -- crash IE5 -- never shows that screen (looks like broken multipart/x-mixed-replaced handling) More testing of other versions of IE would be nice.
IE 6 / Win: 1) Whole last part. 2) I couldn't get it to load any "Please stand by..." page. It always seems to go directly to the bug list. Unless I'm missing something. IE 5.1 / Mac Classic: 1) Whole last part as well. 2) Same... Is it a bug of IE 6 and IE 5.1/Mac that they don't show up any "Please stand by..." page?
> I couldn't get it to load any "Please stand by..." page. It always seems to > go directly to the bug list. Make sure you do a big query. Eg, try to get a list of all resolved or verified bugs. If you still don't see the "Please stand by..." page, that's a bug in IE.
http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=1&votes=&chfield=%5BBug+creation%5D&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Browser&product=MailNews&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time IE6: 1) Load a buglist. Wait for it to completely load. Then view source: IE6 -- shows complete HTML source of the bug list 2) Load a buglist. Hit stop on the "Please stand by..." screen IE6 -- never shows the standby screen. Sniffer shows that the server sent the page as text/html in the beginning - it probably detects IE by looking at its user agent string and doesn't bother with multipart. Boris, Sören: It would indicate that IE test is invalid since the document that Bugzilla offers to IE is not multipart anyway.
#28, #29 You're absolutely right. IE isn't getting any multipart version, at least not IE6.
URL to test multipart stuff on: http://www.zbarsky.org:8000/cgi-bin/testMultipartData3.pl It looks like IE5.0/Solaris just flat out does not support multipart content. I seem to recall that the same is true of IE5/Windows the last time I was playing with this stuff, which is why bugzilla doesn't send IE multipart content.
IE 6 / Win says > --Vhg5N7Gbj70Lgs6 > Content-Type: text/html > > <html><body>Hit 'stop' now and view source. You have 10 seconds to do > so.</body></html> > > --Vhg5N7Gbj70Lgs6 > Content-Type: text/html > > <html><body>It's too late now...</body></html> > > --Vhg5N7Gbj70Lgs6-- > Looks like you're right. IE 5.1 / Mac doesn't do it properly either. It first displays the "you have 10 seconds..." page, as does view source. But nothing happens after 10 seconds; it doesn't load the other parts.
My answer to the question "What should view-source show on a multipart page"? is "All the data as it came from the server raw". This is what is currently saved to the file when you use view source. The Mozilla web-sniffer displays everything. http://webtools.mozilla.org/web-sniffer/view.cgi?url=http%3A%2F%2Fwww.zbarsky.or g%3A8000%2Fcgi-bin%2FtestMultipartData3.pl The Mozilla browser should do the same. n.b. The web-sniffer displays the http headers, I wish the browser made it easy to display the headers (I know it can be done with about:cache-entry). View source in IE 5.01 SP2 on Windows NT displays --Vhg5N7Gbj70Lgs6 Content-Type: text/html <html><body>Hit 'stop' now and view source. You have 10 seconds to do so.</body></html> --Vhg5N7Gbj70Lgs6 Content-Type: text/html <html><body>It's too late now...</body></html> --Vhg5N7Gbj70Lgs6-- So IE gets the view source right but renders incorrectly. It shows the page as --Vhg5N7Gbj70Lgs6 Content-Type: text/html Hit 'stop' now and view source. You have 10 seconds to do so. --Vhg5N7Gbj70Lgs6 Content-Type: text/html It's too late now... --Vhg5N7Gbj70Lgs6--
#34 I agree. When I'm seeing a page, and go to "View Source", I expect to see the source of what's currently displayed, no matter how it got there (through POST, through redirects, through multipart, etc.).
Quite a few dupes!. Pushing for 1.1 beta just because of the number of duplicates.
Target Milestone: mozilla1.0.1 → mozilla1.1beta
*** Bug 154409 has been marked as a duplicate of this bug. ***
*** Bug 155662 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.1beta → Future
I am not sure if the URL given in the bug is appropriate any more. I can not see this problem since the latest upgrade of Bugzilla. I could not test the URLs given in the comments, because none of them could be reached. If anybody has a URL to test this bug in the current builds, please change the URL field of this bug. 2002111208 trunk for MacOS9.x.
The url in the url field works just fine to show the problem. We now "show the source", but we in fact show the entire multipart document (all parts, including the separators) and we do no syntax highlighting.
Not seeing this bug on 1.2.1. Just HTML, fully syntax highlighted.
I wonder how you managed that, since it's quite broken in every single nightly from then to now... Perhaps you're spoofing the IE UA string so bugzilla sends you different content (since IE can't handle multipart/x-mixed-replaced content at all).
Yes, that's it exactly. I didn't realize that would have an effect.
*** Bug 205875 has been marked as a duplicate of this bug. ***
*** Bug 213146 has been marked as a duplicate of this bug. ***
*** Bug 222441 has been marked as a duplicate of this bug. ***
Original testcase worksforme with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 (1.7 RC2). Resolving.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
This is still a problem. There have been no changes in the code that could have fixed it. Reopening. Note comment 44, just in case.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
You definitely know better than me. But I tested it with clean program folder and new profile. No ua spoofing, no extensions. Firefox is wfm too. Is it possible to be a Linux-only issue now?
By wfm do you mean you get HTML source or the raw multipart text? See comment 42. And no, this is XP. If there are platform differences, they are in the server-side sniffing (and should be fixed).
*** Bug 245276 has been marked as a duplicate of this bug. ***
You are right, sorry for the unecessary spam. My resolution was based on what I could recall from the first appearance of this bug (thn a blank page and a save prompt). I should have read some later comments more carefully.
Assignee: harishd → nobody
Status: REOPENED → NEW
QA Contact: moied → parser
Summary: View Source tries to DL Bugzilla buglist as multipart/x-mixed-replace → View Source shows the entire multipart response on a Bugzilla buglist (was: tries to DL Bugzilla buglist as multipart/x-mixed-replace)
This is really Networking rather than Parser. However, as long as we do support multipart/x-mixed-replace, it's semi-useful to see it all and, OTOH, it's not worthwhile to spend time on polishing multipart/x-mixed-replace support.
Status: NEW → RESOLVED
Closed: 16 years ago → 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.